The MIDI 1.0 specifications... and no one followed it

[SuperG]

@PaulWalmsley

Yes, quite possibly, in the same way that the DAW hides the two separate parts of MIDI pitch bend messages in a single ‘pitch bend’ lane. It’s just arguably a bit weird if you have a CC7 lane that actually edits CC39 too. If you have a lane called ‘MIDI Volume’ or ‘MIDI Volume (CC7+39)’ then that’s less surprising because the DAW has abstracted the individual events into a single controllable value.

Just for note, it’s also just as weird considering when one makes a mental mnemonic of program change control CC0/CC32 -‘ala’ YAMAHA/XG, and then later considering it as 14bit. We generally thing of CC0 as being our program of 1-128 - but what to do with CC32? Do we now all go with 14bit program numbers?

Someone at Yamaha gave this a bit a thought and decided ‘no - we’ll consider CC32 to be a sort of specialization pre-select’ in our documentation. In that way, we still think of CC0 program changes as as being a 7bit value, and CC32 being a specialty or variant select such as KSP, stereo samples, and so on. This was a great solution that worked well with what Roland had started with CC0, and intelligently expanded it - Treat the values as separate, but related.

But with all that, Cubase sits on the fence, still today. If you use a midi port without a known device, it’s Bank/Program as displayed in the Inspector. If you have use a defined MIDI device, it’s another matter altogether. A defined midi device, if it has a program table is treated as a single datum, albeit labeled with a program name.

As a programmer, I do ‘get’ it. In reality, all program changes are 14 bit, despite how we mnemonically treat them. But it was a bit of a culture change, coming over from from Cakewalk back in 2018 (the great migration?). Cakewalk had also treated a program as being a tuple (two 7 bits datums), not a singleton 14 bit value.

I keep a YAMAHA MU100 and its original manuals here at home in my rig. I consider it my MIDI 1.0 ‘rosetta stone.’ It could and still does polyphonic aftertouch, back in the day!

*****And now back to our regularly scheduled thread…

Postscript, and beating that horse one more time:

When I mentioned Cakewalk treated bank/programs as a tuple, note that the bank had a name there as well. Therefore if you think about it, every program had two names, just like people a bank name and a program name. You could reference a sound by it program number or name, (1-128), but to be precise you needed to also specify it’s bank number (1-128) or name. Treating both names as one, or in the numeric case as single 14bit number, is akin to using someone’s full name, versus just their name. Which to use depends on context. In MIDI 1.0 we generally just used the the patch name as equivalent to the program name, but in the context of some bank. Cakewalk mere ‘formalized’ it (like a full name ) so both bank and program text were always displayed.

[Brian_Roland]

@SuperG

If you use a midi port without a known device, it’s Bank/Program as displayed in the Inspector.

My understanding over the years. I haven’t extensively tested all of this with the latest Cubase 14, but AFAIK, it should still behave this way…

If there is no special MIDI device assigned (simply connected directly to a physical MIDI port), banks can be entered into the track inspector in 14bit format.
This is essentially the same as:
(MSB*128)+LSB

The ‘Program Change’ is something on its own. The standard is to send:
Bank Change
then
Program Change

So, to call up the Piano 1 sound (CC0 MSB=121, CC32 LSB=0, PC=0) in a GM2 instrument I’d do this math.
(121*128)+0 = 15488

For the Program Change in this ‘track inspector’, Cubase uses the Yamaha convention numbering programs from 1-128 (as opposed to 0-127). So I’ll add 1 to ‘program 0’ and put that in the second field.

Thusly, when a project is first loaded, Cubase track inspector will send:
CC0=121
CC32=0
PC=0

Optionally, you can ignore the track inspector and enter bank changes as separate CC0 and CC32 events in the list or key editor, and enter your program change (Yamaha convention, add 1 if your list of patches are numbered 0-127 instead of 1-128)

One advantage to doing this instead of using the Track Inspector fields, is you can be assured the Bank Change and PC Events will be chased (re-sent every time the sequence plays…as opposed to one time when the project loads).

If you create a proper “MIDI device” in Studio/More Options/MIDI Device Manager…

You can build a patch list.
Such a patch list can use either format. CC0 (MSB) and CC32(LSB), or the 14bit format. These patch lists can be built and entered via ‘patch scripts’, or through the MIDI Device Panel building utilities (linked in an earlier post).

Note, here I made one for a Fantom XR using the 14bit format.

Notice how I went to the trouble to add extra info like the bank names in my Fantom, plus the MIDI Bank and Program info when I named these patches. It comes in handy to have all that info right there in case I want to manually poke in changes later in the sequence. I don’t have to drag out the old paper manual to quickly find things…no matter how I choose to ultimately ‘dial them in’ and get it ‘sent’ to the Fantom.

I believe one can elect to use the two sperate CCs when building a patch list instead of the 14bit format if preferred. Cubase is going to send the same thing either way. CC0, then CC32.

After building such a list, you get a popup to choose patches…

Again, I believe selecting patches from such a list only sends the bank/program change once upon opening a project (or any time you right after you change it to something new)? There is no way that I’m aware of to use this pop-up list to ‘change programs’ in the same track elsewhere in the project. So, I usually make a habit of entering this stuff in the list or key editor. The list comes in handy in beginning stages to try out patches and such, but if you want it more hard coded into the sequence, or wish to ‘change patches’ throughout the sequence, enter them manually, and no, the list won’t ‘chase’ and display these changes.

It IS possible to ‘export’ MIDI files that will include track inspector entries (Pan, Volume, Bank/Program), but one must set this stuff up in the Cubase Global Prefs.

Some instruments only need the MSB or LSB.
Some use both.
Some totally ignore bank change events.

In either case, you can still choose to enter ‘bank changes’ in Cubase in the 14bit format, or the two separate CCs.

I.E. A 14bit entry for an instrument that only uses MSB, just enter 0 for the LSB in the equation:
(MSB*128)+0
Cubase should send:CC0 = MSB, CC32=0

I.E. A 14bit entry for an instrument that only use the LSB would be:
(0*128)+LSB
Cubase should send CC0=0, CC32=LSB

Ultimately, Cubase sends the two bank change CCs (0 and 32) out of the MIDI port.

[SuperG]

Hi, Brian,

I’m afraid I’ve hijacked the thread with my thoughts on data representation, but it appears the OP did get the point he wanted to make, thankfully.

I’m aware of all the numerous ways in which we can send program changes, either directly in the midi or by using instrument definitions and their patch scripts. Thanks for your detailed response - it’s a gift to the community to make detailed posts, you never know who might learn some fact or insight that they didn’t know before but will turn out to be a boon for them.

I think, If I could sum up the minor, low-level MIDI irritants that I have with Cubase (and these are indeed minor bordering on the absurdum, so take the salt) is its default XG-Device script, and the way it represents patches in the Inspector.

To be honest, there’s nothing wrong with the default XG the script itself - it has all the patches, per the XG spec. But it’s organizational division is by instrument type, and not on bank (or patch variation). It’s a very minor thing, and you can simply go and make your own patch script and organize it by bank - if you can stomach all the tediousness of creating one. In fact, you can organize things in multiple ways in a patch script.

(Aside, I use MidiQuest 13 to automatically generate patch scripts organized by bank. It’s a crusty old application, overpriced, not perfect, but eminently handy when you really need what it can do.)

As I pointed out, once you have a defined instrument with banks and all defined, you need to select patches from the Inspector the way the Cubase designed provided, which is organized by whatever the creator of the patch script deigned to provide. You can’t in a pinch override things in the inspector, say to switch a channel on the fly to a drumkit for example, without either going to the device bank (which really ought to be called mode) assignment page (which is not located in the Inspector), or by bypassing the device and going to a channel MIDI directly (blind) and then inputting the correct CC0/CC32 command into a MIDI list for a channel.

This is all academic, though. There are a million ways of getting things done. Us old dogs have tried most of them. There are time and places though, for discussing how data and ideas, and so on) should (or should not) be expressed or displayed. This thread just happened upon an obscure point that’s been a crick in my neck for a long, long time.

Cheers,
-Gene-

[Nico5]

@mlib

You have any examples of devices, software of hardware, that employ such magical algorithms?

Maybe I’m mistaken, but when it was no longer necessary to fade out audio clips manually many Cubase generations ago, that was some of that magic at work, where Cubase automatically created a slope that was just enough to avoid the clicks at the beginning or end of audio clips.

Automatic crossfading is more magic.

Both of those are algorithmic solutions solving problems caused by step “jumps” in audio.

I haven’t worried about accidentally creating a zipper noise with my plugins for a long time. Is that because I’m turning the knobs of my MIDI controllers too slowly or is it because modern well-written audio code makes sure there’s no zipper?

[Brian_Roland]

@SuperG

I’m afraid I’ve hijacked the thread…

I don’t think so…
Apologies if some think I got carried away. Sometimes people get into the retro kit and don’t know these things are still possible with Cubase…

@SuperG

I think, If I could sum up the minor, low-level MIDI irritants

I definitely have a list of those. Particularly with ‘plugins’ that still require some old school MIDI coms like MTS, sysex, and program changes. Seems like way more VST3 plugins are broken in these respects than work properly [I.E.Korg Collection] (and they don’t have a working VST3 parameter workaround either).

I’ve since stopped trying to use those kinds of plugins directly in Cubase, or avoid them all-together, but there are a couple that I miss. Regretfully got rid of my MU series stuff a long long time ago, but still have projects that can be fun to revisit. Running the Yamaha S-YXG stuff through jbridge is one such example (Now if I need those, I host them externally, talk to them over virtual ports, and loopback the audio into Cubase with something like ASIOLink, or hard patching).

Kind of ironic that I find myself getting retro kit out of the closet more these days because the ‘all software’ clones of them don’t work properly anymore.

@SuperG

per the XG spec

I’d considered doing a nice XG panel in Cubase a long time ago. Being on Windows…I played around with XGedit95 via virtual port and decided it wasn’t really worth the effort since XGedit95 did everything I needed and then some.

Same for the Fantom X. I did a basic patch list a few basic ‘setup’ sysex things, but the X Editor thing through a virtual port was so well done I didn’t see the point.

[SuperG]

Hi Nico,

I can answer this one for you.

IMHO, the zipper noise of the past was probably more due to ‘dumping’ than anything, same as the old MIDI devices were limited in polyphony. Whenever more notes arrived than the MIDI unit could handle at once, it would toss notes with no where to go on the floor - into the void of the ‘bit bucket’ as they say. Now extend this concept out further to it’s ability to process sequential control commands and you can see where the possibility of dumping may happen there too.

To be fair, this is all dependent on the implementation of such a MIDI device. In those days, the engineering choices of microprocessor and RAM were tough, high level choices made to hit the twin targets of cost and performance for a given market demographic. The compute power available for a market successful MIDI device was limited back then, and a lot of signal processing was actually done by a custom ASIC. Coupled with the limited bandwidth of the MIDI physical interface, this limited compute power guaranteed that things would be dropped occasionally given the right conditions. Certainly, a missed (or dropped) step(s) would cause cause a jump large than 1 and would be easily audibly notable.

Today, we have compute power and bandwidth coming out of our ears so much that today’s programmers spend it sometimes wastefully. Our biggest issue these days, with DAWs and MIDI devices is in interrupt latency. Computing now runs in the Ghz so that interrupt processing and task switching are now our performance limiting bottlenecks. This is why zipper noise is not a issue today - the sheer speed and brute force of todays microprocessors.

Hope this helps.

[Sergent_Yohann]

Well you can certainly can complain with that to all brand today.
Even arturia aren’t midi compliant, dont be fooled by the physical midi port! The midi for most contollers of their brand is dirivated from usb, so i let you find how much it isn’t midi compliant!
Before 2000 everything worked on Sysex.
NRPN/CC for basic command!
I personally thing sysex is the best!
NRPN although has much data consuming are more like a more flexible CC but still are linked to midi channel!
The supernova II for example relying on CC/NRPN, just cannot be remote in layer patch, because all NRPN use 1 channel in this case what a shame.
There wouldn’t be any issue if sysex were used!
Regarding high res parameter, well really don’t see the use for most of them!
The motif es allow for example 16535 value on time delay, and that’s not useful at all, who care about 1/10ms of precision in this case, 1653ms , well would be better, but already 13ms step of 127 are making 1653ms, and 13ms step to hear them…
Regarding cubase the device panel is certainly the most frustrating unfinished features one for years, but there no one offering better!
And when you don’t have to use buggy crashing not free vst just for controlling devices, but something totally integrated like the device panel, well it’s paradise! (after hell doing them)
And today midi unfortunately is a relic for most user 100% virtual, so don’t expect any better handling in the future for most brand! (not sysex,NRPN, some cc by luck)
I was expecting more with midi norm Following from brand, but it was totally reversed to quite nothing in fact, whereas midi will always remain the most reliable music hardware control protocol for me!

[SuperG]

@Brian_Roland

I definitely have a list of those. Particularly with ‘plugins’ that still require some old school MIDI coms like MTS, sysex, and program changes. Seems like way more VST3 plugins are broken in these respects than work properly [I.E.Korg Collection] (and they don’t have a working VST3 parameter workaround either).

I hear you, Brian.

(Really enjoying this thread, BTW. I do love the old stuff)

I think Steinberg’s intent with VST was while respecting the past of MIDI, to break free of its limitations. Focus on the best parts of MIDI, support the existing ways, and provide a path forward from that.

I think with VST 3, Steinberg decided to make somewhat of a break and drop some of the problematic parts of the old ways. That would be RPN, NRPN, SysEx and things like that. Those things were always compromises made back then to solve problems then that don’t exist today.

Business typically prefers to collect rent than to pay programmers and so if there’s a way to cut corners (and get away with it) they will. If this means a plugin dropping modes and feature that were supported by special MIDI commands in the past (and neglecting to replace them with VST parameter equivalents), there you are. It’s my opinion that VST2 only overstayed its expected lifetime due to this fact, and that only Steinberg pulling the plug on VST 2 support is what is slowly driving the life out of VST 2. ME- I’m all VST-3 today. I’ve still got the MU if I want to go MIDI hardcore, though. LOL.

[Brian_Roland]

@SuperG

I think Steinberg’s intent with VST was while respecting the past of MIDI, to break free of its limitations.

All true. One good thing about the MS Windows on Intel/AMD world, at least for now, is it’s always a piece of cake to roll back to legacy software. Takes only a few minutes to swap boot/system drives and be back in nineteen ninety weird

True about the ‘intentions’ of VST/AU/AAX/CLAP/etc, but very few plugin makers bother to give us replacements for pretty important ‘antiquated ole MIDI’ features. I guess not enough people care or demand it, so why bother?

Modern plugins with only a few exceptions often don’t do MTS, and are a pistol to micro-tune in real time. The plugins, nor the hosts aren’t really supporting that note specific VST-tune parameter, or Note Expression, or MPE, etc. To even try the user must do manual mind-numbing pitch bend calculations and attempt to fudge it in somehow. They’ve ripped out protocols for supporting basic clocks and stuff independent of the sample rate, and don’t give the user access to basics like the current project sample count, let alone song position/tempo/time-sig/etc. I suppose part of this is because VST2 was pretty dependent on specific Processors/Instruction sets being there…ARM can’t do it ‘on the die’, and they don’t want to pay patent fees to incorporate the instruction sets forever (just a short while with stuff like Rosetta), so VST3 requires a whole different approach (hopefully it won’t care what processor is in use, but there’s no quick and easy compiler that’ll just replace it with something VST3 compatable…manual grunt work)? Limbo for a while…

It’s one thing to pull support for the ‘old standards’ when the new stuff is ‘ready’ to replace it. It’s something else when there’s not really anywhere to go but to pull out retro options and try to get it working again.

Most of the newer plugins give you no way to change patches/sounds in real time (Program Change broken, and no need for ‘obsolete banks’). Just have to make a new track and have a new instance. Where scale choices and tuning tables used to be limitless and customizable, these days we often only get a few choices (if lucky), and they can’t be ‘changed on the fly’ short of just moving to new tracks/instances’. So sick of ‘equal temperament @ 440’ on EVERYTHING, and it’s harder than ever to get into variable tuning scales across a broad range of instruments/plugins, yet, 99% of MIDI 1.0 toys could do it, out of the box.

There are a few hosts out there that attempt to give live players more power to remotely drive plugins, lighting systems, and more, all at the same time…but they’re still behind ancient MIDI 1.0 sequencers in so many ways.

The exact same sound that once lived in a few kb of memory, and called for almost no CPU time, can now require several megabytes of memory and make even modern super processors and sound interfaces cry. Stuff needs 4 times the memory and instruction sets to work, yet doesn’t sound any better…sometimes worse.

Oh, and now that tracking in formats that support massive dynamic ranges is not only possible, but almost a no-brainer (endless headroom for mistakes and corrections), you’ll get laughed out of the studio if the mix isn’t so LOUD AND FLAT AND COMPRESSED that it pegs the red line from beginning to end. Different true dynamic levels are NOT allowed (cheap speakers and earbuds probably don’t work well otherwise these days either). So, only a crusty ole BOOMER still using Grandma’s noisy ole power hungry, space heater of an amp and speakers would dare have ‘soft/medium/loud’ variations.

Sometimes it’s almost comical to think about how ‘progress’ works in commercial sectors. Now the dynamic range and computational power is there to expose or hide every performance detail to the inth degree, the ‘consumer playback devices’ and ‘artistic’ trends are that you need 14 plugins to ‘modulate the mess out of it’, ‘noise it up’, ‘and peg out the volume’ until it doesn’t even sound like familiar waveforms anymore, and every frequency competes for the same space in the mix. A nice, clean mix that is easy on the ears, doesn’t fatigue the listener in the first 20 seconds, and doesn’t flat out ‘fry brains’ is ‘so yesterday’.

The good news is that creativity almost has no boundaries anymore. If you let yourself, you can break every trend and rule you like Uber powerful tools are available to anyone for dirt cheap, or even free, and in Windows world, it’s not all that hard to roll back to whatever era of digital Hades our hearts desire (so long as the dongles still work). Cubase, and HALion now that it’s gone dongle free is still pretty solid on legacy support…as much as it can be I guess…will the third party stuff ever catch up (when it comes to supporting legacy features that just no longer work, and need newer methods to do the same things)?

[mlib]

@Nico5

I haven’t worried about accidentally creating a zipper noise with my plugins for a long time. Is that because I’m turning the knobs of my MIDI controllers too slowly or is it because modern well-written audio code makes sure there’s no zipper?

Just to make sure we are talking about the same thing.

This is what I would like to avoid using MIDI CC. This example is using Retrologue but the same behavior can be observed with any soft or hardware synth AFAIK. When using VSTi the obvious solution is to not use MIDI at all for parameter control and use VST automation instead but then we’re giving up hands on control. That could in turn potentially be solved by setting up MIDI Remote in Cubase. (I say potentially because you will need to use a controller that is compatible with the MR . There’s still a little work left to do for Steinberg on MR.)

Don’t get me wrong, I am not advocating that every single parameter has a 16,384 step resolution. In fact, I think 14-bit resolution is a tremendous overkill in almost all instances. But at the same time I feel that 128 steps is not enough in several cases. Cutoff frequency (as demonstrated in the video example above) or any type of frequency parameter, such as the frequency setting of an EQ e.g., are prime examples. Volume/gain in certain cases is another one.

---

@Brian_Roland

Oh, and now that tracking in formats that support massive dynamic ranges is not only possible, but almost a no-brainer (endless headroom for mistakes and corrections), you’ll get laughed out of the studio if the mix isn’t so LOUD AND FLAT AND COMPRESSED that it pegs the red line from beginning to end.

I would start looking for a different studio if that’s your experience.
I personally think this loudness war is slowly dying out. Streaming platforms, TV and radio station utilizing normalization processing based on loudness is going to help along with awareness and pushing back on mastering engineers and/or label execs that still are under the impression that louder equals better. That goes for both creators and consumers.(Join the war against the loudness war!)
I hear plenty of newly recorded music that is wonderfully dynamic and it’s not limited to small indie releases either. I’m hopeful.

[Brian_Roland]

@mlib

This is what I would like to avoid using MIDI CC.

I know that one…

That’s when it got necessary to dig deeper in the instrument presets and fiddle with the patches themselves. Use the built-in envelopes, LFOs and ‘stuff’.

It could be time consuming to sort indeed. Even if you knew where to go and what to do, it was ‘soooo much fun’ having to pad a few buttons a zillion times because the UI was just a 1"X3" display…with a melting backlight, and a dead cricket that somehow got behind the glass.

[mlib]

@Brian_Roland

That’s when it got necessary to dig deeper in the instrument presets and fiddle with the patches themselves. Use the built-in envelopes, LFOs and ‘stuff’.

Yup. Sometimes you can find workarounds like that. Sometimes, and I’m thinking of analog gear in particular, it’s better to give up the idea of automating a parameter via MIDI and just record a live performance as audio.

@Brian_Roland

just a 1"X3" display…with a melting backlight, and a dead cricket that somehow got behind the glass.

Ha! Somehow strangely relatable.

[SuperG]

@mlib

Yup. Sometimes you can find workarounds like that. Sometimes, and I’m thinking of analog gear in particular, it’s better to give up the idea of automating a parameter via MIDI and just record a live performance as audio.

@Brian_Roland

just a 1"X3" display…with a melting backlight, and a dead cricket that somehow got behind the glass.

Ha! Somehow strangely relatable.

Heh.
Reminds me I need to install the replacement display for my old Motu Ultralight that I’ve had sitting around for over a year. Blasted thing obviously blew out its LED backlight, and that LED is not actually accessible on the display assembly.

Thank heavens that the display module is a bog-standard and inexpensive part though. There’s that.

[Nico5]

@mlib

Don’t get me wrong, I am not advocating that every single parameter has a 16,384 step resolution. In fact, I think 14-bit resolution is a tremendous overkill in almost all instances. But at the same time I feel that 128 steps is not enough in several cases. Cutoff frequency (as demonstrated in the video example above) or any type of frequency parameter, such as the frequency setting of an EQ e.g., are prime examples. Volume/gain in certain cases is another one.

Thanks for elaborating. We’re probably much more on the same page than this thread might read like. We may be expressing complementary, but different issues.

When I originally mentioned the MIDI zipper noise, I was thinking of truly undesirable artifacts rather than the result of cleanly applied step functions. But †o be honest, I’m not sure anymore, if my memory serves me right in how that term was originally used back in those days. – So, there’s a good chance that I conflated a different issue into the conversation. Sorry!

---

And you’re totally right, plugins aren’t doing any “magic” in smoothing out stepped filters. And they shouldn’t because stepping has been an important use case for a very long time (Won’t get fooled again).

However, don’t you think we could have smooth filter sweeps without necessarily having to change the protocol?

e.g. Why couldn’t a filter have a portamento analogous to a note? Much like I put my synth into portamento mode (by adding a parameter how long it should take to smoothly sweep from one note to the other), why couldn’t I put a filter into portamento mode by adding a similar time parameter? And then I would play/record/program the filter sweep very much like I would play/record/program a portamento.

For example, I think good tape echo emulating plugins emulate the non- instantaneous change of tape speed even when giving them a step function change of tempo. Or at least it sounds like that to me.

So the idea of interpreting incoming commands as “go to the target smoothly”, rather than “go to the target instantaneously” has been done, and I wonder, if it’s just a bit of a lack of imagination (by software makers or users or both), that it hasn’t been done more?

But having universally higher resolutions in the protocol is definitely nice and most certainly superior for (virtuoso) live performance.

---

Again: I wholeheartedly agree with what you said about some parameters definitely benefiting from higher resolutions. And many (or most) others not so much.

p.s. Thanks for kicking off a very interesting thread!

[Monotremata]

@SuperG

Heh.
Reminds me I need to install the replacement display for my old Motu Ultralight that I’ve had sitting around for over a year. Blasted thing obviously blew out its LED backlight, and that LED is not actually accessible on the display assembly.

Thank heavens that the display module is a bog-standard and inexpensive part though. There’s that.

If its anything like the old 828mk2 you didn’t need to replace the whole thing. The 828mk2’s first run all had the LCD’s burn out within months or release hah. I got an RMA for mine right away but never sent it in to get fixed (I was too busy using it).

The backlight on those was a little SMD LED on the edge of the display. I just clipped it off and soldered a regular old 5V green LED from Radio Shack I had laying around in its place, bent it into place, problem solved.

[mlib]

@Nico5

Why couldn’t a filter have a portamento analogous to a note?

Absolutely! That’s what I was trying to get at earlier when I mentioned that there would have to be a time factor involved.
I think I have only ever seen one device that incorporated that idea. It was a MIDI to CV euro rack module where you would use a MIDI CC to set the time it would take to reach a new value. Very much like a portamento but for parameters rather than notes. I never used the module myself (never got into euro rack at all), but I thought the idea was inspiring.

[SuperG]

@Nico5

And you’re totally right, plugins aren’t doing any “magic” in smoothing out stepped filters. And they shouldn’t because stepping has been an important use case for a very long time (Won’t get fooled again).

D/A A/D chips and software were still rather spanking new bank then.

In mine own experience, I distinctly recall instances where a D/A step caused a spike overshoot in the RF analog circuitry I was driving and had to work with the engineers on the analog side of things to resolve the issue if we had any chance meeting regulatory spectral purity issues. This type of design issue can be the very issue in analog baseband audio circuits as well if not carefully designed. There’s some small likelihood with early software that could simulate a zipper noise, if i.e. somebody forgot to use a log db scale and accidently went linear for a volume attenuation function - things like that. But not likely, and easily fixed. I really feel that the quality of things back them weren’t up to the standards that we take for granted today. There is a impossibly tremendous gap between then and now in technology sophistication, even if it’s only been about 45 years since the 80’s.

Cheers

[Psychlist1972]

You’ll usually find it referred to as “slew” or “slew rate”. Might help if you’re searching for solutions.

Pete

[Nico5]

@SuperG

There is a impossibly tremendous gap between then and now in technology sophistication, even if it’s only been about 45 years since the 80’s.

Having started my computer journey in that decade on mainframes, I’m definitely grateful not having to use Hollerith code anymore. – On the other hand, it could be argued that the MIDI piano roll in Cubase 14 is a close relative.

[SuperG]

@Nico5

Having started my computer journey in that decade on mainframes, I’m definitely grateful not having to use Hollerith code anymore. – On the other hand, it could be argued that the MIDI piano roll in Cubase 14 is a close relative.

Your making me laugh. During one of the last gasps of the FAA’s old IBM 9020 based Air Route Traffic Control Center system, in the early 90’s, I had the fortune to work as a contractor on a PC-based visual graphical map editor (very novel for those old terminal-and-card reader based guys) for the datasets those old machines sent to their plan-view radar displays. It was a fun job - all that data, although on disk, was all formatted just as if it still were on Hollerith. (This was just as GPS was coming online and beginning to reveal huge inaccuracies in the FAA’s geographical datasets)

Anyway - the end of that story was that the project was a success on our part compared to our competition (IBM) because we had used a fixed point integer system with all that geo data so that the program would display all that data very fast on PC’s w/o a floating point coprocessor. Nobody really had them on their PC’s (FPC’s) back then, not even the FAA as the were optional and really freaking expensive. IBM’s pampered boffins totally missed that detail - they produced a product that required one, without it a single screen refresh might take go-get-a-cup-of-coffee’s worth of time.

Today, floating point is basically free, nobody does fixed point anymore.