Thank you everyone for spending time on this.

Just to clarify, I use VSTHost by Hermann Seib (instead of a DAW) to summon virtual synths and effects, something like this:

MIDI in (MIDI keyboard) - Synth - Reverb - MIDI out

And this is what I would like to achieve:

MIDI in - Dirty Pitch - Synth - Reverb - MIDI out

The Dirty Pitch is not intended to produce any sound, just static random pitch bend MIDI messages for the virtual synth to produce an ANTI autotune effect controllable by the user.

So the Dirty Pitch PlugData script, would need to be converted/compiled (or whatever) into a VST3 Plugin format.

Dave S.

I use Facebook groups a lot for posting questions about synths and that sort of thing. However, the Pure Data group on Facebook looks to have fallen out of use.

Pure Data has been on my radar for a while, years actually, but I have tried a couple of times and found it to be a little too much past my level of knowledge when it comes to synths and computers. I think I have become comfortable enough with all the things that provide a good base for learning Pd aside from a good knowledge of programming in tradtionally typed languages. I have been dabbling in Raspberry Pi for years, spent some time using a Ubuntu Studio PC with Waveform and mostly hardware synths, and currently use mainly a Mac for my computing needs.

In this time I tried Patchblocks a couple of times and finally buckled down and actually figured them out. Too bad it was well after they sold their tech to another company and they are no longer widely used. It took me a while to learn enough about synth terminology and their use to become comfortable with that programming system too.

I suppose all the back and forth between different synths and some platforms that are not quite mainstream, (I would include Pd among those), I am finally figuring out the tutorials presented on Pd that I find.

As mentioned in the title of this post, I am working through that book. I had seen that some externals are available on GitHub and decided to give that a go and am posting the patches I make there for others to have a look at if they are interested. Here is that link:
https://github.com/playinmyblues/Working-Through-Pure-Data-Programming-Fundamentals-Vol-1

I also posted the link to that repository on the Facebook group (https://www.facebook.com/groups/puredata). If anybody reads this post that is an admin there, would you mind having a look at my post for approval?

I see that there are a fair number of people whom have joined that group recently so it might still get some traffic and use if it gets some posts.

Just to get the feel of what people are using, what is your preferred way of interacting with people interested in Pure Data? Where do you like to browse for ideas people have, post questions, answer questions, post music, etc.? Thanks.

@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......

Hi, my name is Kane Lister and I am currently studying for my MSc in Audio Engineering and I'm looking to gather some primary research through interviews with members of the PureData community for my case study.

Question will include what different functions do you include in your PureData Synths, what's Synths you like and have you have based any of your synths off of existing synths, etc...

I will be extremely grateful for anyone who participates, thank you.

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

@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.

@Il-pleut Yes.... 250 and 252.
This might interest someone...... https://github.com/IndustrieCreative/Harmonync
I haven't uploaded it so as not to upset @Eeight
Although it was built a long time ago for extended the heavy midi lifting was done including sysex and sysex bulk dumps with checksum (maybe why no-one is having much luck with bulk dumps at the moment)...... sysex.zip
Though mostly Vanilla of course.
David.

@oid said:

@ddw_music Long sysex messages work just fine if you treat them as what they are and what pd is quite good at dealing with, streams.

I do understand what you're saying, and I began with the same assumption -- that [midiout] should be just a low-level conduit -- byte goes in, byte gets sent out.

Unfortunately it doesn't work that way in practice.

My test scenario looks like this. Launch SuperCollider and Pure Data. It helps in my case that I'm testing in Linux, where I can create and remove MIDI connections arbitrarily in qjackctl's ALSA tab.

SC code:

MIDIClient.init;

MIDIIn.connect(0, MIDIClient.sources.detectIndex { |src| src.device.containsi("pure") });

m = MIDIOut(0).connect(MIDIClient.destinations.detectIndex { |dst| dst.device.containsi("pure") });

m.connect(MIDIClient.destinations.detectIndex { |dst| dst.device.containsi("superc") });

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

Then I need to go to qjackctl and connect Pd's MIDI output to Pd's MIDI input.

At this point, I can send MIDI from either Pd or SuperCollider, and both SC and Pd will respond.

Pd patch, implementing "stream of bytes" (btw I tested both [sysexin] and [midiin], no difference in the results):

sysex-stream.pd

(Note also: Because I am collecting the MIDI-in bytes into a list, I also checked whether there is a maximum list length. There may be, but we won't hit any such limit in these tests -- I could go up to 5000 numbers in a list, no problem. So, in case of any message truncation, it must be happening in the MIDI objects, not in list handling.)

The test case will be to send a packet of n 14-bit integers (MSB first). The total packet size will be n*2 + 2, so if we want to produce exactly b bytes, n = (b / 2) - 1.

SuperCollider sending:

(
f = { |n|
    var out = Int8Array[240];
    n.do { |i|
        out = out.add(i >> 7 & 127).add(i & 127);
    };
    out.add(247);
};
)

// small packet
m.sysex(f.value(10));  // SC OK, Pd OK (22 bytes)

// 512 bytes
m.sysex(f.value(255));  // both OK

// 514 bytes
m.sysex(f.value(256));  // SC OK, Pd did not print

And my results for Pd sending:

• 22 bytes (n = 10): Both OK
• 512 bytes (n = 255): Both OK
• 514 bytes (n = 256): SC did not respond. Pd printed only 512 bytes (truncated).

Conclusions:

• When SC sent 514 bytes, SC received 514 bytes, so we know SC is sending a complete packet.
  • Pd did not respond, suggesting that both [sysexin] and [midiin] simply stopped listening after 512 bytes, did not process the ending delimiter, and thus did not output the packet at all.
• When Pd was asked to send 514 bytes, Pd received only 512 bytes. This suggests that [midiout] is buffering the incoming bytes, waiting for a complete packet before sending, but it must have a limit of 512 bytes, causing the message to be truncated. (And SC didn't respond at all, which suggests that the closing delimiter was never sent.)

So again... in principle, you're correct -- it's technically possible for some [midiout] object to relay the data out, byte by byte. But neither [midiin] nor [midiout] are implemented that way.

hjh

@lo94 said:

I think I understand what you're saying but because of the formatting of the template file I'm having a hard time applying it to this use case (as I'm used to relatively short sysex messages like the one shown in the forum thread, where this one is massive). I attached the file in case it would be useful/relevant to see

In theory it would be something like the attached. But, I haven't gotten the entire sysex to be received on the other end. (EDIT: When you click 'dir' at the top, the number box will show 240... not done in this screenshot.)

sysex.pd

The right hand [print] shows that the entire file is being sent to [midiout].

For receiving, I tried two tests:

• SuperCollider, like before. If I send separate messages [240 1 2( and [3 4 247(, then SC's sysex handler does assemble them into a single packet -- so there should be no problem with sending sysex in chunks. But when I send the entire file (in chunks), SC never receives the terminating 247 -- then, if I send 247 on its own, it outputs all of the bytes stored so far!

• Pd. In qjackctl (I'm in Linux), I connected Pd's MIDI output port to its own input port, and try to collect sysex bytes in Pd itself. ([midiin] gives access to raw incoming MIDI bytes, which SC doesn't.) [midiin] gets only 512 bytes.

There are two possible explanations for the 512-byte limit. One is that perhaps [midiin] buffers the input -- but I think we can reject that explanation, because [midiin] outputs the bytes one by one, suggesting no internal processing.

The other would be that [midiout] is trying to collect an entire sysex packet, and that this imposes a limit of 512 bytes. The fact that neither Pd nor SC got the 247 terminator is consistent with this.

Unfortunately, that's bad news for your use case. There appears to be no alternative to [midiout] here, and AFAICS it would require a software change to extend the outgoing packet size.

hjh

Thanks for the replies. I will have to spend some time staring at this as I am relatively new to the world of sysex. I've sent sysex messages for simple cases like program changes, but with this one I have a rather large file as I realized a workaround to a potential limitation with my MIDI Controller (Novation SL25 MK1) with templates (limited number) and PureData is that PureData could basically just send the giant template sysex file to the controller based on MIDI messages. These templates are stored in temp memory, so basically all my custom PureData patches don't need to actually be saved within the synth, and I can save the template storage for my hardware synths. Essentially just pass the template file to the synth as needed from PureData, which automatically loads it up in temp memory when it receives it

I think I understand what you're saying but because of the formatting of the template file I'm having a hard time applying it to this use case (as I'm used to relatively short sysex messages like the one shown in the forum thread, where this one is massive). I attached the file in case it would be useful/relevant to see

FirstButtonCC.syx