For the Blofeld editor, well, it's a one way communication editor(for now), the editor only sends data to Blofeld, I can not change a parameter directly on Blofeld and then the editors parameter follows. I didn't do that yet, but it's on the to do list.

In my last post, when I refer to a sound dump, it's the same as a patch dump. But what I did there was only to start the sound dump on Blofeld by sending the "request sound dump" sysex string from Pd to Blofeld, to dump the current sound from Blofeld and then receive the sound dump in Pd. I did not try to decode the sound dump to get the individual parameters. So can't use that for the Dx7 approach.

I did get an idea from your posts, though, how I might be able to "backwards engineer" the sysex patches from Dx7:

1. Use the free Dexed dx7 and export a patch sysex dump for reference.
2. Then use the same patch and change ONE single parameter and export the patch as sysex dump.
3. Compare the two sysex dumps and see which values have changed. The value changed is the parameter I am looking for. I can then assign it to a fader in my Dx7 editor.
4. Do it a few times with a few different parameters, until I find a pattern. Or just do it for every single parameter, to be on the safe side......
   (Dexed Dx7 editor/Vst - https://www.kvraudio.com/product/dexed-by-digital-suburban/downloads)

I know, it's not the smartest way, but it worked for Blofeld and since this is "only" around 150 params in total it should be manageable, as a weekende project

About the 32 voices, ahh yes, you are probably right, it's the amount of presets, not actual polyphonic voices. Would love to get that working too, to get all 32 voices/presets of a voice card dump. There are a lot of them around.

Thanks again. I actually though sysex messages for full patch dump was more complicated. If all parameters are just individual numbers in the sysex string, it's doable, just a bit time consuming.

@jaffasplaffa hmm well whatever way you were getting sysex into the editor might work. (idk if you did individual parameters in, or if the blofeld had a sysex patch dump like the dx7?)

as far as I understand it the values will come in sequentially so all you have to do is look at the reference of the sysex you have and route the incoming value to the appropriate location depending on how many values have been received so far, and the value of "format number" which will be the 4th value received, if you want to use both 32-patch sysex dumps and single-patch sysex dumps.

you might need [list store] with [list tosymbol] to construct the patch names

by "voices" I think they actually mean patches, since the dx7 was monotimbral. A single cartridge had 32 patches on it it seems. (the bass sysex file you provided is one of these; if you open it in a hex editor with character display you can see the names of the patches every 128 bytes)

Hey Seb!

I appreciate the feedback

The routing I am not so concerned about, I already made a nice table based preset system, following pretty strict rules for send/recives for parameter values. So in theory I "just" need to get the data into a table. That side of it I am not so concerned about, I am sure I will find a way.

For me it's more the decoding of the sysex string that I need to research and think a lot about. It's a bit more complicated than the sysex I used for Blofeld.

The 32 voice dump confuses me a bit. I mean most single part(not multitimbral) synths has the same parameter settings for all voices, so I think I can probably do with just decoding 1 voice and send that data to all 16 voices of the synth? The only reason I see one would need to send different data to each voice is if the synth is multitimbral and you can use for example voice 1-8 for part 1, 9-16 for part 2, 17-24 for part 3, 24-32 for part 4. As an example....... Then you would need to set different values for the different voices. I have no plan to make it multitimbral, as it's already pretty heavy on the cpu. Or am I misunderstanding what they mean with voices here?

Blofeld:
What I did for Blofeld was to make an editor, so I can control the synth from Pure Data. Blofeld only has 4 knobs, and 100's of parameters for each part.... And there are 16 parts... So thousand + parameters and only 4 knobs....... You get the idea

It's bit of a nightmare of menu diving, so just wanted to make something a bit more easy editable .

First I simply recorded every single sysex parameter of Blofeld(100's) into Pure data, replaced the parameter value in the parameter value and the channel in the sysex string message with a variable($1+$2), so I can send the data back to Blofeld. I got all parameters working via sysex, but one issue is, that when I change sound/preset in the Pure Data, it sends ALL parameters individually to Blofeld.... Again 100's of parameters sends at once and it does sometimes make Blofeld crash. Still needs a bit of work to be solid and I think learning how to do this decoding/coding of a sysex string can help me get the Blofeld editor working properly too.

I tried several editors for Blofeld, even paid ones and none of them actually works fully they all have different bugs in the parameter assignments or some of them only let's you edit Blofeld in single mode not in multitimbral mode. But good thingis that I actually got ALL parameters working, which is a good start. I just need to find out how to manage the data properly and send it to Blofeld in a manner that does not crash Blofeld, maybe using some smarter approach to sysex.

But anyway, here are some snapshots for the Blofeld editor:
Image of the editor as it is now. Blofeld has is 16 part multitimbral, you chose which part to edit with the top selector:

Here is how I send a single sysex parameter to Blofeld:

If I want to request a sysex dump of the current selected sound of Blofeld(sound dump) I can do this:

I can then send the sound dump to Blofeld at any times to recall the stored preset. For the sound dump, there are the rules I follow:

For the parameters it was pretty easy, I could just record one into PD and then replace the parameter and channel values with $1 & $2.

For sound dumps I had to learn a bit more, cause I couldn't just record the dump and replace values, I actually had to understand what I was doing. When you do a sysex sound dump from the Blofeld, it does not actually send back the sysex string to request the sound dump, it only sends the actual sound dump.

I am not really a programmer, so it took a while understanding it. Not saying i fully understand everything but parameters are working, hehe

So making something in Lua would be a big task, as I don't know Lua at all. I know some C++, from coding Axoloti objects and VCV rack modules, but yeah. It's a hobby/fun thing I think i would prefer to keep it all in Pure Data, as I know Pure Data decently.

So I do see this as a long term project, I need to do it in small steps at a time, learn things step by step.

I do appreciate the feedback a lot and it made me think a bit about some things I can try out. So thanks

@jaffasplaffa I think your biggest problem will be routing the info of the various parameters to the appropriate locations. I guess the way to do it might be to have a giant [route] with a counter, for each type of sysex? basically you need a state machine with a counter that counts how many parameters have been received, and changes the routing depending on the values of previous received values

if you want to do the 32-patch sysexs you will need to do some bitshifting of some of the inputs for a few parameters too.

tihs type of thing is really better accomplished in a text format I think, perhaps look into pdlua or py/pyext or pdjs.
if you use one of these you might be able to simplify things by having an array with the name of a recieve, so you can just count the parameters and send to an appropriate receive by reading the right value from the array.

another way to do it would be to have each receive follow a specific naming format (like $0-param0, $0-param1 etc.) and then look up the appropriate number in an array for the different types of sysex. Then you can just change the send name depending on which parameter is being sent using pd's built-in message formatting with $1 etc.

how did you do it with individual sysex parameters?

Here is some info on the sysex format, which I grabbed from the free Dexed Dx7 vst's github page:
sysex-format.txt

Here is a sysex file for a bass sound patch:
BASS001.SYX

After looking a bit into it, I am pretty sure it's doable, just going to take a while to completely understand it. But I think it's doable

Hello

I have been using the Really Useful Tutorials DX7 patch for a while now and it's really cool.

I was thinking if it would be possible to take it to a next level, by implementing sysex compatibility, so the Really Useful Dx7 synth could load the thousands and thousands of sysex DX7 files that can be found on the web?

I have used sysex message i PD before, for a Waldorf Blofeld editor, with success, but not like this. For that editor, I used sysex for individual parameters, which is something completely different.

How would one go about loading a sysex patch file in Pure Data and then get the individual parameters(is that called decoding a sysex file?) from that sysex file and set the values to the correct parameters in the Really Useful Dx7 Pure Data synth?

If possible at all......

Thanks in advance!

Jakob

@Organism Here are the abstractions, it will ignore the first tick from the controller and just highlight the control to be edited and keep the CC value and the slider/numberbox2 up to date with each other so you can edit on the screen or with the controller and avoid all parameter jumps. The help file shows how to use the note data sent by the BeatSteps pads to switch what controls the encoder edits, but that can be switced to a radio or another CC like the tempo knob on the beatstep. As is this is setup to work with relative CCs centered on 64, but it would be simple to change it to work on other values,

cc.zip

@jameslo To my knowledge all of the Arturia controllers and sequencers can be set to send relative CC data, the one caveat is that if you do not have access to a Windows or Mac computer to run their software it can be difficult to change the controllers settings, Arturia has not been good about releasing the sysex for their gear and not all of their devices have had people figure out the sysex and post it on the web. Thankfully it is not hard to figure out the sysex, if you have access to a Windows or Mac machine at least. The regular BeatStep is the only device that I know of which has had someone do the work and publish the full sysex of on the web, I think one of the Keysteps has a good portion of its sysex posted, the rest just have bits and pieces scattered about.

That was the problem, all is well and the data is filling the array exactly as expected. Regarding the sysex, this message is a single complete sound, each number between F0 and F7 is a parameter in the synth and indexed just as the array is, 1 is VCO1 Octave, 2 is VCO1 semitone, 3 is VCO1 detune and so on, so the plan is just to set the receive symbol on a [nbx] to correspond to its parameters spot in the array, n1, n2, n3, etc, then the counter stepping [get array] and [pack] to get the full symbol and data for [send] to send off to the [nbx]s, seems simple. The data sent to the synth will be as CCs and short single parameter sysex messages, parsing the full sysex for the sound just seems so much more sensible than sending 350 or so individual sysex parameter requests.

7F is just every parameter I have set at full in that patch A few Dozen of the 00s are reserved bits used internally within the synth though, it is not quite all fun stuff.

Thanks for your help!

Ahhh my patch wont work, you have to change the final message box- I messed up the order of the parameters.

Let's go over it:

240 - status
64 - manufurer id

• Channel number ($1 in argument, $2 in message)
  16 - sysex function
  0 - Group num (not sure what this is may be internal external storage)
  3 - Machine ID number
• parameter number ($2 in argument, $3 in message box)
• source number (1 - 4 audio sources) ($3 in argument, $4 in message box)
• parameter value ($1 in message box)
  247 - end

So, your message box should read [240 64 $2 16 0 3 $3 $4 $1 247(

sysex.pd <- fixed version

I am working on using a pd patch to send MIDI sysex parameters to control a Kawai K1r synthesizer parameters. My current patch is working however I would like to make my code more "resusable",

My patch consists of a slider with an outlet to a int object that converts the slider value into a whole number, then out to a message object that contains the complete decimal code for the sysex message. I have a $1 at the position where the parameter value should change, so the int object value is inserted into the message string at that point. Then the message is sent out to the midout. I am able to use the slider in my PD patch to change the value of a parameter and see and hear the changes from the synthesizer. My patch currently has 1 slider.

I intend to set up sliders for many parameters, and would like to avoid copying the full sysex message for each slider. It would seem preferable to store the "header" of the sysex message as a constant or global variable and build the sysex string by concatenating 3 or 4 parts; the header, the parameter number, the parameter value and the end of message.

Below is an example message in decimal values:

240 64 0 16 0 3 15 0 $1 247

Reading this left to right, I only need to change the 7th and 9th values in the sysex string. How do I go about doing this in PD?