@lacuna said

And single precision is not enough for you?

I'm not sure what you're asking. I'm saying that doubles are required to capture [phasor~]'s state, so in that sense singles are not enough. But otherwise they are. And singles are OK for everything in my patch as long as I accept that I have to disrupt the double accumulation whenever I snapshot.

Do you know what is not working in Pd64?

In my real patch? No. But I should've said earlier that WRT state saving, things were working well enough last week to stop working on this problem (and finally switch back to making music). I started this topic just to report on the most interesting thing I learned during the 2 weeks I spent debugging my poor patch

Did you think about other ways, like rec/playback?

Yes, that's what this is for, to record snapshots of my chaotic patch to REAPER as sysex so that I can return to the exact same state and fiddle with things to make them sound better. I had to capture the values of 32 floats--20 were UI controls but 12 were the states of things like phasors, sampleholds, rzero-revs, and arrays used for feedback. I think we may be thinking slightly differently about recording, so let me tell you how I use it. My patch is kind of unpredictable, and I'm just randomizing its UI controls on a bang to see what I get. Each time I randomize them, I take one of these snapshots. When I'm listening back later, I might want one of the snapshots to be longer, so I just go to the sysex track and add time. Or I might go back and fiddle with the UI a little, then take another snapshot. The sound associated with each snapshot is not steady-state--it might do something surprising if you let it run long enough--so that's why recording the sound is not enough. But it's also true that you don't need any more data than those 32 floats to get back to where you were, no matter if you're only interested in the next second or the next 3 hours.

RE ppphasor-repeat, Pd is complaining about non-existent arrays. If you feel like fixing that, then you might also want to add something that tests whether the repeat is a sample-for-sample copy of the original. That's what I was starting to add before I noticed the error messages.

Well, I ended up having to use %.8e because %.7e did not quite capture the precision of many floats, but I tried to make up for the bloat by encoding all ints between 0 and 999999 as %i. Sadly, it's still not compact enough because I think [sysexin] is dropping characters somewhere around the 400 char mark. Here's a test patch that demonstrates it on Win10, i7-5960X @ 3GHz, 32G RAM using loopMIDI for loopback. Monitoring the loopback channel with PocketMIDI shows that the char drops are not happening in loopMIDI.
sysex test.pd

I've returned to the possibility of encoding floats as 5 7 bit words, i.e. 4 bytes with 7 significant bits and 1 byte with 4 significant bits. If I was doing this in C, I'd access the single as though it were an unsigned long and extract 4 or 7 bit chunks using masks and a bit shifts. In Pd, I see that there is else/float2bits. I also see iemlib/float24 which suggests that there might be a different way, but maybe not. Are there more convenient ways of accessing the bits of a single precision floating point? And converting them back? Converting back seems to be tricky--not sure if it's possible to compute the single prec float from exp, sign, and mantissa in binary.

Edit: holy smokes, I just coded up something naively and it seems to work:
floatTo7Bit test.pd


I mean, look at that [expr]: how is it possible to multiply $f1 by pow(2, -23) and then add one to it without incurring the wrath of the overflow/underflow gods???!

@midi said:

I need to output “note on velocity 0”
to the software

the software refuse to recognize
any note off messages

I just tested as follows (sending a nonzero midinote number of course):

... and found that (at least in Linux, using the ALSA MIDI protocol) [midiout] transmits the bytes exactly as given, without transforming note-on to note-off.

I don't know about Mac or Windows MIDI behavior.

But... when I set up a MIDI responder in SuperCollider (because SC distinguishes between noteOn and noteOff, unlike Pd where velocity is the only thing that distinguishes them), I found that SC changes in note-on message with velocity = 0 to a note-off message.

When I set, in SC, MIDIIn.noteOnZeroAsNoteOff = false;, then the zero-velocity message was received as note-on.

Now, that's not a guarantee that it will do this on all platforms. But, I don't find anything in Pd's sources that changes the status byte in this case. So if that's definitely always happening in your environment, then it must be either PortMIDI in Pd, or the receiving software is doing it.

hjh

I've been storing floats in sysex messages using fudiformat and restoring them using fudiparse, but this suffers from the same display format truncation that many Pd float persistence facilities do. For instance:

It's a tiny difference, but one of my patches is sensitive to it.

I started to make something to break up the 32 bits of a single precision float into 5 words, 7 bits each, but I forgot that the bitwise operators in Pd convert the float to an integer first. Silly moi.

When I'm just saving to and restoring from a file, I use an array as intermediate storage and then use soundfiler to write/read the array to/from file. I just tell soundfiler that the array contains 4 byte samples. But it would be nice to use sysex so that I can record, edit, and playback a sequence of them. Is there a way to do this?

@whale-av said:

So if you have a slider sending to [midiout] on a channel then probably "vinyl control" could learn the parameter.

In Pd: I put a vertical slider connected to [midiout] object.

In learning mode ("vinyl control"), moving the slider in Pd, Mixxx says:

Didn't get any midi messages. Please try again.

a.

@ChicoVaca I don't know about other DAWs, but REAPER can record and playback sysex in time just like any other MIDI message. It's not so pretty to look at and edit, but you can move sysex events along the timeline, copy and paste sysex phrases, etc. Is that what you meant?

@jameslo So my memory fades..... sysex will not pass through "Studio Manager"...... it reads it but will not send it on to the desk.
The desk will not send NRPN when it receives SYSEX.

OK..... the parameter change sysex messages are 01v96 specific...... see "01V96 Parameter Change List.xls".... inside the folder "01v96_midiptcl100".
Other desks respond to the same messages if the header is changed.... see the begining of my first ever post on a forum for details..... "Totally Remote 01v96 - REV1.5.doc"

The complete midi spec is also inside the "01v96_midiptcl100" folder.

The NRPN folder contains all the NRPN addresses for the desk, in Decimal.
I remember that you have to select NRPN in the 01v96 midi setup to use it.
NRPN is faster than 14-bit sysex...... most of the desk faders use values in 10-bit.... 0-1023.
but some controls are 14-bit and some 16-bit.

The sysex (.syx) file contains a mix of messages for a BCF2000 to control parts of channels 1-8 on the 01v96...... including NRPN for on/off....... explanation of my choices for format in "Remote any Yamaha Digital desk"

01v96.zip
David.

P.S. I went from analogue mixers on-stage for the musicians, to a Midi setup as above...... nearly having a stroke when I looked at "Mackie HUI"....
... and then I found Pd.
Best day ever,

Here is the sysex format again just in case......

if you check this thread https://forum.pdpatchrepo.info/topic/377/sysex/32, the last reply from @il pleut shows that a sysex message is a list of numbers that must start with 240 and end with 247.
bearing that in mind I temporarily set the midi output to the equivalent midi input and the result is below
note messages only went midiin
sysex and note messages went to both midiin and sysexin

@whale-av said:

@bang Pretty sure mommuplat will only use vanilla objects.

[sysexin] and [sysexout] are vanilla.

I would test first whether Pd [midiin] receives any data when a sysex message is sent to its channel. If not then you are probably out of luck..... but if the message is received at [midiin] then you can use that with mobmuplat and build something to decipher sysex into your patch.

In Linux, there is a size limit on MIDI packets (512 bytes). Large packets do not appear at [midiin] or [sysexin] outlets.

I could not find whether Pd's PortMIDI usage (which seems to be used for both Mac and Windows) has a similar size limit.

I don't know about mobmuplat -- but, I can say for sure that there is at least one supported platform where, if your device sends sysex beyond a certain size, you won't get it -- thus, Pd can't claim to make a 100% guarantee that large packets will be passed through.

https://forum.pdpatchrepo.info/topic/14028/send-syx-file/11 outlines a test case.

hjh

@bang Pretty sure mommuplat will only use vanilla objects.
But sysex is midi..... so strings of values.
I suggested this https://forum.pdpatchrepo.info/topic/13662/raw-midi-midiout/5 a couple of months ago for sending out sysex messages using [midiout] and there are other threads like this...... https://forum.puredata.info/topic/377/sysex/33 that also use [midiout] to send sysex messages.

I would test first whether Pd [midiin] receives any data when a sysex message is sent to its channel. If not then you are probably out of luck..... but if the message is received at [midiin] then you can use that with mobmuplat and build something to decipher sysex into your patch.
David.