3 ms·

> Most SYSEX dumps are just dumps of the plain ol' structs that the synth engines are using to drive their output. A lot of synths don't have the processing po

> Most SYSEX dumps are just dumps of the plain ol' structs that the synth engines are using to drive their output. A lot of synths don't have the processing power to do more than just dump the struct. I don't think it's processing power: it's stingy RAM utilization. Many bad actors (Kawai, Casio, later Yamaha) did crazy bit-packing of parameters rather than just keep them in a simple array, while the more sane (Oberheim, E-mu, Waldorf, early Yamaha) at least tried to pack in a consistent way. Other bad actors (ahem Korg, as late as 2000) decided to use, shall we say, creative parameter encodings, going even so far as embedding textified versions of parameter numbers into sysex byte streams. And many used all sorts of crazy schemes for banks and patch numbering, most of which are incompatible with one another. And it's not just encoding: basic synth patch dump features are missing from different models. There are five basic tasks that most synth editors require: - Change patch - Request a dump from working memory - Dump to working memory - Dump to patch RAM and save - Send a single parameter change (for any parameter) Manufacturers couldn't even agree to make machines which supported all five of these. Some machines (Yamaha) have no way to write to RAM. Some machines couldn't do single parameter changes. Some machines can't properly change patches in a consistent manner. Some machines have no patch request mechanism. Many machines can't dump to current working memory: only to patch RAM! The situation is only getting worse. Whereas in the past manufacturers at least attempted a complement of sysex messages, now many manufacturers can't even be bothered to allow access to their machines (Korg, Roland). Others treat their sysex messages as proprietary secrets (Arturia, Digitech, Alesis). There is only one truly good, shining actor in the open MIDI spec space, and that is Sequential. Which shouldn't be a surprise given who runs it.

PaulDavisThe1st 7y ago
"Send a single parameter change (for any parameter)" This makes no sense. That would also imply a way to discover (and name, and probably provide semantics for) all parameters. That's a huge ask if MIDI (even MIDI 2.0) is the only communication protocol available. Yes, the first 4 of your list are common. The first one is covered by the core MIDI spec. The 2nd and 3rd have no standard msg, but your complaint seems to be about the contents of the message, which is no business of the requestor. The 4th assumes "patch RAM", which cannot be assumed, as you note, and that seems correct to me.
- SeanLuke 7y ago
  > This makes no sense. Why? It's highly standard. About 90% of the synthesizers I've written patch editors for provide exactly this facility. In fact some (PreenFM2, Korg Microsampler, Futursonus Parva) provide only this facility. > The first one is covered by the core MIDI spec. Actually it's not. Program Change only works for 128 patches. If a synth has more than 128 (and many do), they must rely optionally on Bank Select, but their definitions of "banks" vary because a bank is not a formally defined concept. Some rationally treat banks as divisions of the patches. Others treat banks as media choices: cards versus RAM versus ROM. Some require that Bank Select be immediately before Program Change with nothing in-between; others do not. Some ignore banks entirely and instead define a "Program Change Table" of 128 slots pointing to arbitrary patches in memory, and then Program Change indicates which patch slot to use. And there are several major synthesizers (Yamaha TX81Z and DX11 are famous examples) where Program Change is in fact broken and requires unusual workaround hacks. Further, most synths require a program change prior to a patch load: but others (notably the Oberheim Matrix 6 and 1000) require a program change after a patch load. It's a mess.
  - PaulDavisThe1st 7y ago
    It's not standard at all. There is absolutely no MIDI standard for the contents of a patch. I really don't know what you're thinking of. Back in the 90's, when things like "MIDI Librarians" were common (and widely used), each new device needed to be added to the MIDI Librarian's code to deal with the specifics.
    - SeanLuke 7y ago
      > It's not standard at all. There is absolutely no MIDI standard for the contents of a patch. I really don't know what you're thinking of. I think you may have misread what I had said. I didn't say that patches had to be the same format or content -- that would be insane.
  - PaulDavisThe1st 7y ago
    I don't think it's fair to say that "banks are not a defined concept". What has happened is that many MIDI device manufacturers have stretched and ignored the clear intent of the MIDI 1.0 specification. Reading that, it is quite obvious what the relationship of banks and program changes is. But that hasn't stopped various companies from playing games with the two (as you note) for their own purposes. Nothing will ever do that, fully.
fit2rule 7y ago
>I don't think it's processing power What I mean is that, if they have to reformat their internal struct to conform to a standard, they don't have the processing power to do this munging. Not that they'd care, as you have noted elsewhere.
HelloNurse 7y ago
The point of Sysex messages is moving complexity, such as disentangling bitfields, from the lean hardware of a synth, entitled to do whatever is more convenient, to a deluxe computer that can afford the plasticity of software.

PaulDavisThe1st 7y ago

"Send a single parameter change (for any parameter)" This makes no sense. That would also imply a way to discover (and name, and probably provide semantics for) all parameters. That's a huge ask if MIDI (even MIDI 2.0) is the only communication protocol available. Yes, the first 4 of your list are common. The first one is covered by the core MIDI spec. The 2nd and 3rd have no standard msg, but your complaint seems to be about the contents of the message, which is no business of the requestor. The 4th assumes "patch RAM", which cannot be assumed, as you note, and that seems correct to me.

SeanLuke 7y ago
> This makes no sense. Why? It's highly standard. About 90% of the synthesizers I've written patch editors for provide exactly this facility. In fact some (PreenFM2, Korg Microsampler, Futursonus Parva) provide only this facility. > The first one is covered by the core MIDI spec. Actually it's not. Program Change only works for 128 patches. If a synth has more than 128 (and many do), they must rely optionally on Bank Select, but their definitions of "banks" vary because a bank is not a formally defined concept. Some rationally treat banks as divisions of the patches. Others treat banks as media choices: cards versus RAM versus ROM. Some require that Bank Select be immediately before Program Change with nothing in-between; others do not. Some ignore banks entirely and instead define a "Program Change Table" of 128 slots pointing to arbitrary patches in memory, and then Program Change indicates which patch slot to use. And there are several major synthesizers (Yamaha TX81Z and DX11 are famous examples) where Program Change is in fact broken and requires unusual workaround hacks. Further, most synths require a program change prior to a patch load: but others (notably the Oberheim Matrix 6 and 1000) require a program change after a patch load. It's a mess.
- PaulDavisThe1st 7y ago
  It's not standard at all. There is absolutely no MIDI standard for the contents of a patch. I really don't know what you're thinking of. Back in the 90's, when things like "MIDI Librarians" were common (and widely used), each new device needed to be added to the MIDI Librarian's code to deal with the specifics.
  - SeanLuke 7y ago
    > It's not standard at all. There is absolutely no MIDI standard for the contents of a patch. I really don't know what you're thinking of. I think you may have misread what I had said. I didn't say that patches had to be the same format or content -- that would be insane.
- PaulDavisThe1st 7y ago
  I don't think it's fair to say that "banks are not a defined concept". What has happened is that many MIDI device manufacturers have stretched and ignored the clear intent of the MIDI 1.0 specification. Reading that, it is quite obvious what the relationship of banks and program changes is. But that hasn't stopped various companies from playing games with the two (as you note) for their own purposes. Nothing will ever do that, fully.

fit2rule 7y ago

>I don't think it's processing power What I mean is that, if they have to reformat their internal struct to conform to a standard, they don't have the processing power to do this munging. Not that they'd care, as you have noted elsewhere.

HelloNurse 7y ago

The point of Sysex messages is moving complexity, such as disentangling bitfields, from the lean hardware of a synth, entitled to do whatever is more convenient, to a deluxe computer that can afford the plasticity of software.