Enhancing your MIDI devices with Perl
fuzzix.org
fuzzix.org
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.
It seems to be confusing however, because it's been discussed here previously https://news.ycombinator.com/item?id=29888845
Isn't it a reference to "the featured article"?
$ 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);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.
Simply being "new" does not mean "better," except for those who merely seek novelty.
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.
Really? That's a remarkably readable Perl code, actually.
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.
it’s not entirely fair, but on the bright side, at least there’s a kind of logic to it.
"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.
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.
> 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.
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...
name another language that did what perl did in its salad days, especially wrt being a super-shell unix scripting language
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.
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?".
A tortured piece of awk code is like a beautiful rose, sharp, but wax poetic. Perl is like a corpse flower.