@whale-av said:

@lo94 [midiout] requires decimal....... and a sysex file will be in Hex (almost certainly)....... https://forum.pdpatchrepo.info/topic/377/sysex/32

Well... maybe.

For instance, https://mido.readthedocs.io/en/latest/syx.html has a section for "SYX files -- reading and writing," and another section for "Plain Text Format" sysex files. So, apparently, there are two ways that sysex could be written to disk -- a sequence of bytes (numeric), or as text, where each byte has been encoded as two hex digits.

"read_syx_file() determines which format the file is by looking at the first byte. It raises ValueError if file is plain text and byte is not a 2-digit hex number."

Sysex messages are supposed to be introduced by a byte F0, and terminated by F7. So you could do as this site suggests -- read one byte, and if it == 240, then treat it as a byte stream.

I have no idea whether binary or hex-coded sysex dumps are more common in the wild, only that at least one reference page implies that both exist.

It is possible that a whole sysex dump can be passed in one message (still decimal though) to [midiout], but I have no means for testing that.

I just tested this by having SuperCollider print out sysex messages -- that is, there is no need to have a MIDI device receive sysex.

MIDIClient.init;

// '5' is Pd's MIDI source in the device list
// may vary in your system
MIDIIn.connect(0, 5);

MIDIdef.sysex(\y, { |... args| args.postln });

[240 1 2 3 4 247( --> [midiout] then caused SC to print: [ Int8Array[ -16, 1, 2, 3, 4, -9 ], 8454145 ] = data block, and device UID (where -16 = 0xF0 and -9 = 0xF7, as signed 8-bit ints).

hjh

@lo94 [midiout] requires decimal....... and a sysex file will be in Hex (almost certainly)....... https://forum.pdpatchrepo.info/topic/377/sysex/32
Hex/decimal conversion can be done easily in Pd since version 0.48
Hex.pd
You will need to drip [list-drip] the symbols into the "symbol representation" box and group the messages that you send to [midiout] starting a message when you drip 240 (F0 hex) and ending the message when 247 (F7 hex) has dripped.... rinse and repeat (see link above).
[list-drip] [select] and the messages [set( and [add2( will be your friends.
handle.zip (Hex.pd included)

It is possible that a whole sysex dump can be passed in one message (still decimal though) to [midiout], but I have no means for testing that.
David.

@fina said:

I'm especially worried about multi mapping the controls to different pages/layers and how the controllers behave if the pot/encoder is in a different position

This can be a pain, faders (unless they are motorized) will jump, if you are at midi value 10 and switch too a different mapping that has that fader at max, when you move it it will jump down to 10, quite annoying but can be exploited and was a common trick on the early synths with patch memory that used analog controls, but this was generally more a hindrance than a help. Most modern controllers use endless rotary encoders which will update their values, in absolute mode you map out the controls on the controller itself and make presets, switch the mapping and the new values are there so no jump when you turn the knob but this has the disadvantage that they generally are limited to the low resolution 0-127 midi values. In relative mode the encoder sends only a plus or minus value so you can have unlimited resolution but you need to do more in pd since you need to add or subtract those plus or minus values from a stored value.

Personally I find mapping controls on a controller to be slow and I do need greater resolution so I do it all the mapping and the like in pd with relative mode, I made some abstractions to take care of all the work and they do some useful things like the first tick is ignored and just highlights the parameter being edited so when you forget what knob does what you can find your way without altering anything that is going on. This also means you are not limited by the controllers memory for mappings, I just do that in the patch so I have a virtually unlimited number of mappings. I use an Arturia Beatstep as a controller, 16 pads and 16 encoders, so each pad selects a mapping giving me 256 parameters I can edit or if I somehow needed more I could arrange the pads as 8 banks of 8 and 1024, but I have yet to need to do that. It also has the sequencer mode which is very limited but handy as an easy way to easily test sounds out. I can upload these abstractions if you decide on going with relative encoders, been on my list to get those uploaded but I tend to drag my feet on documentation so they have yet to get a proper upload, they have been uploaded a few times in various threads just not everything with actual documentation.

One thing to keep in mind, some controllers have software editors to make it easier to map stuff out, these software editors often do not work in linux even in Wine, so if you use linux you will want to make sure that the sysex commands have been published either by the maker or by someone who has sat down and figured them all out. For what ever reason some companies just will not release the sysex (Arturia being one of them). It is not terribly difficult to figure out the sysex on your own, just time consuming.

@JOO What software synth are you using? In my case I think Mohave didn't come with a GM synth installed (like Windows 10 does), so I had to install SimpleSynth and configure it to read from the bus.

I feel so foolish answering Mac set up questions because I'm usually the one asking them Here is someone who had the same problem 10 years ago: https://forum.pdpatchrepo.info/topic/4119/general-midi-au-dls-synth-where-oh-where

UPDATE: 2023-01-11:

I just noticed the zip was missing the needed [sc] abstraction to play the tester. Have updated the zip below to include it. Please, accept my apologies for the deficiency. -PTS-LTM, s

the5basicmodulation-synth-types-2(w-missing-sc).zip

(no other changes)

Before I built Jass~(Gemini) I first had to spend a lot of time gathering together all the information I could about all the basic synth types.

This patch consolidates all 5 of the basic types (additive, frequency, phase, pulse, and amplitude) under one heading so that they may be more quickly, easily, and readily comprehended.

It includes selectors for the carrier and modulator wave types, as well as, the two basic controls for each type, and an array so you can both see and hear how those basic types look, feel, and sound.

It's also just sort of cool to listen to.

I hope it may make it easier for you to digest the (what may initially seem complex ideas) more readily and conveniently.

Note: the floss-manuals have a lot to say about it, but leave off some stuff. And the audio-examples -help files are spread out across a lot of space and leave off the viable ranges for each control/parameter.

Good luck! Happy PD-ing. Stay healthy and

Peace through Music and Love through sharing.

p.s. if you find something that is "wrong" about the patches, in terms of how that type of mod is suppose to work, please, let me know, as I did have to guess about a lot of stuff and would love to learn.

Hi everybody,

I'm trying to build a polyphonic synth which let me control many parameters with midi cc.

First I create a synth. Then I use the object clone to multiply it.

Then I used the objects poly to have many voices of polyphony and it works well, but apparently poly use only note and velocity informations.

So I tried to create a second inlet on my clone object to control one of the synth's parameters. The result seems to be random and it affect only one synth's instances.

I'm blocked at this point.

Can someone show me the way?

Thanks

That synth has a fairly standard patch layout so you could download the sysex patch file for a similar synth and throw together a quick patch to convert the sysex patches into the needed format. Should get the sounds close enough and probably would take less time than compiling a pile of patches from people and you can include that patch with your MobMuPlat patch so people would be able to use any patches people have made for the donor synth.

@jaffasplaffa I don't see why you don't just use the reference .txt you have, that seems way easier than having to export a sysex and compare it for every parameter.
Anyways, the sysex will be serial so "which parameter" it is will be based on what # of message it is in the input stream when you read the sysex. (though idk what you're going to use for getting the sysex file in - [mrpeach/binfile], or sent over midi using something like sysex librarian https://www.snoize.com/SysExLibrarian/)

the full 32-patch format is different than than the single-patch format though so the parameters will have different positions in each.

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)