Enhancing your MIDI devices with Perl(fuzzix.org)
fuzzix.org
Enhancing your MIDI devices with Perl
https://fuzzix.org/enhancing-midi-hardware-with-perl
42 comments
Why “TFA” instead of just “the article”? I understand “RTFA”, berating commenters who didn’t “read the fucking article” with a cheeky acronym, but TFA by itself is kind of hostile for no reason. Unless you hated the article that much
In my mind, RTFM is read the fucking manual, but TFA is the fine article.
It seems to be confusing however, because it's been discussed here previously https://news.ycombinator.com/item?id=29888845
It seems to be confusing however, because it's been discussed here previously https://news.ycombinator.com/item?id=29888845
> TFA is the fine article
Isn't it a reference to "the featured article"?
Isn't it a reference to "the featured article"?
I thought it was "Read The Fantastic Manual" ;)
Couldn't get the code to run with Perl on Mac:
$ plenv exec perl midi.pl
Not enough arguments for main::pedal_notes at midi.pl line 107, near "$note)"
BEGIN not safe after errors--compilation aborted at midi.pl line 150.
MIDIIn.addFuncTo(\noteOn, ~myNoteOnHandler);People still use Perl?
I do, all the time
What else are you going to use to list ecclectic rubish?
Perl is a great scripting language to stitch together high performance C binaries. Not to mention that CPAN and the built in debugger are awesome.
Write it in Perl to deploy quickly and replace pieces with optimized binaries as needed.
It’s still used for new projects in far more places than a lot of people might realize.
Write it in Perl to deploy quickly and replace pieces with optimized binaries as needed.
It’s still used for new projects in far more places than a lot of people might realize.
Yes. A mature and well-understood tool does not cease to exist nor cease to be useful simply because new tools exist.
Simply being "new" does not mean "better," except for those who merely seek novelty.
Simply being "new" does not mean "better," except for those who merely seek novelty.
I always hated Perl.
This library does sound interesting and maybe Perl would be less painful for me now with a language model.
The article is great right until it gets into the perl code.
My brain just turns off and my eyes want to cross.
This library does sound interesting and maybe Perl would be less painful for me now with a language model.
The article is great right until it gets into the perl code.
My brain just turns off and my eyes want to cross.
> The article is great right until it gets into the perl code.
> My brain just turns off and my eyes want to cross.
Really? That's a remarkably readable Perl code, actually.
Really? That's a remarkably readable Perl code, actually.
Old people who don't want to learn new things... (We'll get downvoted but it's true.)
This kind of closed mindedness is part of a huge shift in programming culture since the heydays of Perl.
Someone can post a tortured looking piece of awk code here and people applaud. Post the same thing being done in Perl and we are likely to see comments like these — despite the fact that the Perl version will almost certainly be more readable and maintainable than anything you can write in awk.
It’s sad to see this happen to such a revolutionary-for-its-time language.
Someone can post a tortured looking piece of awk code here and people applaud. Post the same thing being done in Perl and we are likely to see comments like these — despite the fact that the Perl version will almost certainly be more readable and maintainable than anything you can write in awk.
It’s sad to see this happen to such a revolutionary-for-its-time language.
Maybe, but that revolutionary-for-its-time language is now a language that uses "long dead" stack based conventions. We don't balk at it as an alternative to awk, we balk at it when it's used instead of a modern scripting language like Python, JS, or even "in betweeners" like Lua or Go.
Python is less than 5 years younger than Perl. JS is less than 10 years younger. Your examples are both three decades old.
More importantly: why does reading about someone using Perl cause you to “balk”? That’s the issue my comment was lamenting, this attitude that everyone should be using something “acceptable”.
Before Perl, it was mostly unacceptable to use a dynamic language in a business. That sea change alone is revolutionary enough that you’d think there would be some room for a little respect or even curiosity, if nothing else.
But that’s not the case and I think that this kind of ahistorical close mindedness (not specific to Perl, to be clear) is a newer feature of programmer culture. And I think it’s worth lamenting its pervasiveness.
More importantly: why does reading about someone using Perl cause you to “balk”? That’s the issue my comment was lamenting, this attitude that everyone should be using something “acceptable”.
Before Perl, it was mostly unacceptable to use a dynamic language in a business. That sea change alone is revolutionary enough that you’d think there would be some room for a little respect or even curiosity, if nothing else.
But that’s not the case and I think that this kind of ahistorical close mindedness (not specific to Perl, to be clear) is a newer feature of programmer culture. And I think it’s worth lamenting its pervasiveness.
Indeed, but while those contemporaries (really? a decade difference? In programming land? That's multiple paradigm shifts but sure why not) grew up and evolved to keep appealing to an every changing crowd, Perl 5 didn't, for better or for worse.
But compared to C style languages, it's going to be "for worse". Perl code is not easy to read unless you already know Perl, or someone intentionally wrote it inefficiently enough to be easy to read to people who don't.
That's why I balk at it. Using Perl in 2025 because you have to: sure, we all have responsibilities. Using Perl in 2025 because you like working in it: also sure, enjoy what you enjoy. Talking about the Perl code you wrote to do something cool: pretty cool, nice job! But that won't stop me from also going "but: really? Perl? In 2025? You couldn't have picked a modern language?".
But compared to C style languages, it's going to be "for worse". Perl code is not easy to read unless you already know Perl, or someone intentionally wrote it inefficiently enough to be easy to read to people who don't.
That's why I balk at it. Using Perl in 2025 because you have to: sure, we all have responsibilities. Using Perl in 2025 because you like working in it: also sure, enjoy what you enjoy. Talking about the Perl code you wrote to do something cool: pretty cool, nice job! But that won't stop me from also going "but: really? Perl? In 2025? You couldn't have picked a modern language?".
Python moved on. Perl is still stuck in about 1998.
There seems to be a lot of generalized nostalgia for the 90s at the moment. 1998 might not be such a bad place to be stuck ...
[deleted]
Nah I feel the same way for Awk.
> It’s sad to see this happen to such a revolutionary-for-its-time language.
Revolutionary? Please. It was certainly a decent-for-its-time language. I used it a lot! 25 years ago. Why on earth would you use it today though? We have so many better options. Even Python is better at this point.
> It’s sad to see this happen to such a revolutionary-for-its-time language.
Revolutionary? Please. It was certainly a decent-for-its-time language. I used it a lot! 25 years ago. Why on earth would you use it today though? We have so many better options. Even Python is better at this point.
If it allows you to be productive and fits the way you think, why not use it? And what is your metric for "being better"?
Languages don't really exist in isolation, especially general purpose languages. They depend on community for things like libraries, support, compiler & tooling development, etc.
You can use a dead language if you want, but you're going to lose out on all of that. And you'd better not ever want anyone to help you with your projects...
You can use a dead language if you want, but you're going to lose out on all of that. And you'd better not ever want anyone to help you with your projects...
AWK is Posix. Python is not. End of the story. POSIX awk will run everywhere, and GAWK has networking capabilities.
Personally, I find Perl’s modern object modules interesting and fun. And I’ve always liked the fact that many Perl built ins were based on POSIX, which doesn’t seem common in other languages.
>Revolutionary? Please.
name another language that did what perl did in its salad days, especially wrt being a super-shell unix scripting language
name another language that did what perl did in its salad days, especially wrt being a super-shell unix scripting language
> Someone can post a tortured looking piece of awk code here and people applaud.
A tortured piece of awk code is like a beautiful rose, sharp, but wax poetic. Perl is like a corpse flower.
A tortured piece of awk code is like a beautiful rose, sharp, but wax poetic. Perl is like a corpse flower.
it was severely overused in the late 90s. its versatility made it very bad for large projects, but people used it anyway because it handled CGI easily. people who were there still bear the scars, and language hipsters know it isn’t popular, even if they don’t know why.
it’s not entirely fair, but on the bright side, at least there’s a kind of logic to it.
it’s not entirely fair, but on the bright side, at least there’s a kind of logic to it.
While I agree that there's been a decided shift towards one-try-language-ism these days, there always were complaints about Perl's readability. Mostly because its heydays didn't quite coincide with good programming practice, both the early Perl4 admin scripts that replaced the horrible mish-mash of "standard" user space of the commercial Unices, and later quick-fire CGIs.
"Proper" procedures and tooling were less involved there, if they were present in the Perl version of those days in the first place. (And also Python wasn't a horrible feature creep blob back then, so shone in comparison)
Perl had and has a lot more to offer than that, but many people didn't come across that. Of course these days purity tests are much more involved, and many people wouldn't even dare touch languages where there's no type system that could launch a 1000 ships of PhD's writing theses about it. ;)
Having ranted that, it feels a bit odd to argue about this in a thread about MIDI. Where you're likely to connect to a plethora of synths from the 80s that have the combined computing capacity of a pregnancy test. Where using an Atari ST from '85 to sequence things is still a viable option. Where DIN plugs are the state of the art, like on your oldest Model M.
"Proper" procedures and tooling were less involved there, if they were present in the Perl version of those days in the first place. (And also Python wasn't a horrible feature creep blob back then, so shone in comparison)
Perl had and has a lot more to offer than that, but many people didn't come across that. Of course these days purity tests are much more involved, and many people wouldn't even dare touch languages where there's no type system that could launch a 1000 ships of PhD's writing theses about it. ;)
Having ranted that, it feels a bit odd to argue about this in a thread about MIDI. Where you're likely to connect to a plethora of synths from the 80s that have the combined computing capacity of a pregnancy test. Where using an Atari ST from '85 to sequence things is still a viable option. Where DIN plugs are the state of the art, like on your oldest Model M.
> Where you're likely to connect to a plethora of synths from the 80s that have the combined computing capacity of a pregnancy test.
In 2025, the most likely use for MIDI to connect very contemporary control surfaces with deliciously formed rubber pads and smooooooooth endless rotary encoders to synth plugins that use so much CPU they couldn't have run on an 80s computer, and likely not even one from the mid-2000s.
> Where DIN plugs are the state of the art, like on your oldest Model M.
Almost all current MIDI devices use USB. A few don't even offer DIN anymore.
In 2025, the most likely use for MIDI to connect very contemporary control surfaces with deliciously formed rubber pads and smooooooooth endless rotary encoders to synth plugins that use so much CPU they couldn't have run on an 80s computer, and likely not even one from the mid-2000s.
> Where DIN plugs are the state of the art, like on your oldest Model M.
Almost all current MIDI devices use USB. A few don't even offer DIN anymore.
DIN plugs are greatly preferred over the cursed 2.5mm TRS with a different polarity depending on which manufacturer one is addressing
I'm not old, I know other things. Still, I use Perl.
This looks like a rad API
What TFA refers to as latency is the time required to inject a MIDI event/message received by RtMIDI into the perl async object - basically inter-thread wakeup. You certainly expect that to be very, very fast - it's what context switching on any multitasking/multithreaded system relies. "Fractions of a millisecond" is in the right ballpark, though on some systems "Tens of microseconds" would be more appropriate as a description.
What "latency" normally means in the context of MIDI or audio is the delay between the user generating a MIDI event somehow and when the audio corresponding to that MIDI event (e.g. a note) is audible. This is typically measured in relatively small numbers of milliseconds (e.g. 1-30).
These are not really connected in any meaningful sense.