Hello, I have been working with making an editor for a synth and am having some issues. I am doing a program dump of the synths working sound to populate the number boxes with the correct values, [sysexin] seems to be working for that and when connected to [print], every thing comes out neatly on the console, 382 separate prints each with one parameter. So I connected [sysexin]to a [tabwrite] and a counter to step the index of tabwrite, standard [f] and [+] counter. This does not work, data is coming through incorrect and it only steps through 247 of the arrays index, results are almost consistent, but there are some differences between dumps., generally an impossible number or two well beyond what two digit hex can represent. Running on linux and pd 49.

Any ideas as to what I am doing wrong, or better way to accomplish what I am attempting?

Edit: Forgot I just updated, running pd 50.2

@oid Very hard to help without seeing the data.
Sysex is defined as a standard that allows manufacturers to define their own data format... so every device is different.
Generally each data set starts F0 hex and ends F7 hex..... but the length of the data in between is variable. It contains manufacturer and device Id's (device id and device number if set) so that a return message is filtered correctly, and then parameter id and a data set for the parameter.
[sysexin] is Linux only so I have never used it but I believe it prints comma separated values in decimal.
So you need to look for 240, ?, ?, ?, parameter, data, 247 where ? and ? and ? are always the same, and then maybe save the data sets using [text].
David.

@whale-av, Here you go.
dumps
first column is the hex patch dump right to amidi and is 100% confirmed correct, second column is the output of [print], third column is the array and the fourth column is also the array, not sure what happened there but it seems to be counting instead of gibberish now. Might just be my tired eyes missing something in the patch, here is the patch.

back to gibberish output, my changing [f] to [i] had caused it to count, turning it back to [f] reverted it back to much the same as column 3. Why the difference between float and integer here?

@oid You are not counting because you are just taking the data values.
You need a [1( message between [sysexin] and your counter if you want a sequential count 1... n

You will need to reset [f] and [+] to zero before a new dump.
The data will take longer to look at...... maybe this evening.

But before I go out..... the first column is hex
The second column (from sysexin) is decimal equivalent of the hex, and is correct.
The whole of each column is one message, from F0 (240) "start of new message" to F7 (247) "end of message" that must be kept together.
If you plan to edit the message and send it back to the device you are going to need to know what exactly each bit of data represents.

So you need the owners manual for the device.... or you can look for clues in the data...... https://sound.stackexchange.com/questions/23983/what-is-the-most-effective-way-to-reverse-engineer-sysex-format-for-my-old-yamah
7F probably marks the end of a parameter message.
David.

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!