There's some confusion at the end of TFA about latency.
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.
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
that's... extremely silly. the confusing thing is why wouldn't you just write "the article"? what's the point of the abbreviation if you don't mean to convey the swear word?
$ 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.
I got something similar working in Supercollider though, which has a lot of tools for these sort of things, eg:
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.
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.
> 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.
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.
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.
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?".
> 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.
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...
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.
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.