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!

Honestly never really used regular computer synths much, but started doing some daily eartraining with Syntorial and got to trying to remake some of the synth sounds in PD. Two questions:

How are low-pass filters constructed in a standard computer synth? They have a 0-1 value in Syntorial (and presumably other synths). To reproduce that in PD I'm multiplying 0-1 by 30 (arbitrary value so that the sound stays pretty bright when the lop value is at 1) by the frequency of the pitch being filtered and putting it into a chain of [lop~]...

Syntorial's sawtooth and pulse(square) sound pretty clean, but in PD they have a lot of frequencies below the ground tone that make the sound very noisy. Are these filtered out with [hip~]s?

Also, anyone know any nice PD patches that regulate a standard synth setup? Might be interesting to analyze them.

edit: just noticed the thread two lines below this one, so I'll check that out...

Hello,
I'm new with PD. Currently I'm working on an audiovisual project. For that I use a polyphonic synth I found on the patch-repository called SYNTH-0. I uploaded my modified version (for use in purr or l2ork) here.SYNTH-0.5.zip . With it I'm trying to send values to VVVV, which does all the visual part.

Now from this patch I would like to send out 4 numbers of the 4 voice signals as they go through the filter & adsr-envelope. I've gotten pretty far. The problem is the following: the patch uses the "poly"-object, which routes the midi-input 4 times to a subpatch called voice, which then again contains the envelopes and produces an output.


Within "voice" I attached a number-box and an object to send to my sending subpatch, which transfer data to VVVV via FUDI. The thing is: with that I get numbers for one out of the 4 voice patches, I'd like to receive all 4 of them in a pack however. If I attach a numberbox in a subpatch that is 4 times called the same name but is factually 4 different instances, how does pd make the decision which of the 4 to send out with a send object? Might be that I'm missing out on something fundamental about subpatches. Glad for any help!

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?

@CrouchingPython Pd has midi output...... and you could connect an external synth and select it from the Pd "Media" "Midi Settings".
But if it is a software synth on your computer then you need to loop-back the output of Pd to the input of the software synth.
In Windows you could use loopMIDI........... http://www.tobias-erichsen.de/software.html
Open it and set up a loop (there could well be one opened straight away by loopMIDI..... then open Pd and connect to it....... and open your software synth and connect to it.........

Widows10 might still have "Microsoft GS Wavetable Synth" still built in, but some say it doesn't work and Google will find you plenty of free and better ones.
The Arturia is a controller...... it outputs midi messages the same as Pd....... and still needs a synth (something to make the sounds when triggered by midi messages).....
David.

I'm currently working on a program bank / state saving system for my external synths to exceed their memory capacity, and to create an easy approach to performance using the limited gear I possess.

The gist is that I use an APC 40, and have pure data switch LED lights referencing either a patch or state.

Each program references a loaded sysex message which creates the base sound. Between songs, or when inaudible. A state is a list of any values safely transmitted as CC data without interrupting the external's sound (pauses, etc). These switches happen while sound is transmitted

Signal flow example:

iemmatrix - first two relate to x-y coordinates of LED, followed by 42-2 as CC-Value Pairs
4 1 matrix 42 2 5 0 6 0 7 127 10 64 12 20 13 82 14 4 15 0 18 1 19 64
20 127 21 115 22 0 23 0 24 0 25 0 26 88 27 127 28 70 29 64 30 64 31
64 59 0 70 74 71 29 72 84 74 70 73 4 75 0 76 47 77 54 78 64 79 120
82 127 83 43 85 85 87 0 88 85 89 0 92 0 93 0 94 0```

[row(
|
[matrix]
|
[route 5 74 72, etc]
|               |           
[ctlout 5]    [ctlout 74]  [etc]

This solution works, even though it looks slightly silly in the route object extending out for however many CCs.

I was more concerned with efficiency than something conveniently dynamic. There is a slight "catching up" effect, whether it's from the external synth or the current rate of transfer I'm not completely sure. Without a method to test this(?), it's all in the ears. However I'm interested in eliminating all potential bottlenecks outside of the actual transfer rate from my usb midi - to external synth.

If anyone has a recommended potential alternative, which may be more efficient I'd be grateful. Or some foresight to say "it can't get more efficient, it's midi. Have a cookie" Thanks.

hi folks, thanks for the kind comments!

sure ill share the patch eventually but right now its an uncommented messy laboratory affair. best thing you can do right now is look at the patch image above which is quite self explanatory.

here is the vs rom in one wav file, scan this in 128 chunks of 128 samples and you have the single wave data.

vsallwaves.wav

harmonic aliasing is best described by acreil in the above mentioned blog post because thats where i got the idea from. the rest is trial and error and a lot of listening to integer combinations.

harmonic aliasing is actually my own term for what im trying to do. here is how i would describe it:

• if you repeat 128 samples with a phasor at 128 hz (or 64/32/16/8/4/2) or any multiple of 128 your phasor restarts exactly at the beginning of the wave data and the aliasing frequencies generated by the steppyness of the data will follow the harmonic overtone series 1,2,3 etc. depending on the multiple.

• if you introduce another prime divider ie. 3 as in 128 / 3 the phasor will line up with the sample data every 3rd sample and the osc will alias at the 3rd subharmonic frequency which will be somewhat more disharmonic than any overtone.

• another way to look at it would be the pattern repetitions. at subdivision 5 the phasor starts at 5 different points in the sample data and its easy to imagine that the readout patterns are all slightly different ... but the whole thing cycles after 5 phasor rounds = 5th subharmonic..

• if you subdivide 128 further with a higher prime ie. 563 you will get 562 different sounding samples until nr. 563 lines up again. get the idea?

this is all very easy to hear once you experiment with prime subdivisions and multiplications. just remember its all based on synching the data flow from the sample with the frequency of the index phasor. this will work with ANY sample data, the vs rom is just cool to use for vintage synth fans.

whats important for proper aliasing is that you use a simple [tabread] into the data without any interpolation like tabread4 or oversampling!

all the other elements in the synth like delay, waveshaper, sequencer follow the same rule as they are just repetition devices like the wavetable oscillator.

if you finally synch everything to the sample rate of your soundcard the voltages that hit your speakers will repeat in exact patterns. thats the idea of this synth: precision number repetition controlled by harmonic/disharmonic integer combinations ... just like the great 80s synths waldorf microwave or prophet vs.

hi all ... im developing a funky wavetable synth thats inspired by the sequential circuits prophet 2000 from 1985. it uses the original 12 bit ROM from this synth and and a synthesis menthod called harmonic aliasing.

• all frequencies and repeat rates are related by simple integer relationships
• adaptive just intonation = infinite tuning systems
• 3 oscillators per voice
• wavetables by multiplexing oscs with waveshaped sines
• variable sample rate simulation via resampling with audiorate wavetables (BLITs)
• integrated complex numeric sequencer
• integrated delay for hardware mixer feedback loop with analog eqs

basically it includes everything i think is cool about numeric sequencing and is still really low on dsp because its all based on integers mechanics like early wavetable synths.

this synth can sound really ambient or real raw depending on the complexity of the number relationships and the waveshaping settings. eventually this is going to be a hardware synth with FPGA technology, variable sample rate per oscillator and analog eqs/filter ... just like in the 80s

project logo:

https://i.imgur.com/F1kqrMt.png

prototype patch:

https://imgur.com/XpxKxA3

wave multiplexing:

https://imgur.com/O2Ze6a1

.

harmonic aliasing is inspired by a patch by acreil: https://forum.pdpatchrepo.info/topic/6759/new-anti-aliasing-and-phase-distortion-abstractions.

early discussion: https://forum.pdpatchrepo.info/topic/11176/adaptive-sample-rate-and-harmonic-aliasing-in-pd

.

mixer delay feedback loop feature:

lots of different sounds with audiorate waveshaping:

.

Okay ;that's what I suspected you were doing. It is possible to use the MTP serial directly with linux and the mtpav driver, though this requires a machine with true hardware parallel port access (USB adapters won't cut it) and is limited to MIDI output only as the driver is a hack that was never finished. I used to run mine that way with a second USB MIDI interface connected to one or more of the MTP's unused routed MIDI outputs (there is, BTW still no way to connect the MTP USB version directly to a Linux system as it doesn't use a standard USB MIDI driver)

As far as the kernel is concerned, I've only ever used lowlatency or RT kernels for MIDI stuff. I don't know how a generic kernel would affect this problem but it's probably best avoided as they are not specifically built for multimedia.

Now read closely as this is where it becomes stupidly complicated.

First, make sure that the problem is internal to Pd. Your interfaces are probably not the issue (since Pd is only seeing the UM-1 driver I don't think the MTP even figures in here). However, the chosen MIDI API can get in the way, specifically in the case of the unfinished JACK MIDI. JACK MIDI presently can only pass SYSEX as short realtime messages. SYSEX data dumps will disappear if sent into the current JACK MIDI system. ALSA works OK. OSS probably too, but I have not tried it.

If that stuff is ruled out and you are still getting problems, it probably has to do with a set of longstanding bugs/oversights in the Pd MIDI stack that can affect the input, output, or both.

On the output side there is a sysex transmission bug which affects all versions of Pd Vanilla before 0.48. The patch that fixed Vanilla had already been applied to L20rk/PurrData for some time (years, I think). The output bug did not completely disable SYSEX output. What it did was to miss-format SYSEX in a way that can't be understood by most modern midi applications, including the standard USB MIDI driver software (SYSEX output from Pd is ignored and the driver/interface will not transmit anything). You would not notice this bug with a computer connected directly to an MTP because the MAC and Linux MTP drivers are programmed to pass raw unformatted MIDI.

If this is the problem and you have to use a pre-0.48 version of Vanilla it can be patched. See:

https://sourceforge.net/p/pure-data/bugs/1272/

On the MIDI input side of Pd we have 2 common problems. One is the (annoyingly unfinished but nevertheless implemented) input to output timestamping buffer that's supposed to provide sample-accurate MIDI at the output (if it was finished). This can be minimized with the proper startup flags (for a MIDI-only instance of Pd, -rt -noaudio -audiobuf 1 -sleepgrain 0.5 works for me) or completely defeated with a source code tweak to the s_midi.c file. This may not be the source of your particular problem as it usually only affects the time it takes to pass messages from input to output, but is worth mentioning as it can be very annoying regardless.

With SYSEX dumps it is more likely that the problem lies with the MIDI queue size. This is very common and I experienced it myself when trying to dump memory from a Korg Electribe Ea-1.. The current version of Pd limits the queue to a size of 512 (even worse it used to be 20) and any input larger than that will get truncated w/no error warning. There is not yet any way to change this with startup flags or user settings. This can only be "fixed" by a different tweak to s_midi.c and recompiling the app.

The attached text files are derived from the Pd-list and will show the specific mods that need to be made to s_midi.c.

pd_midi_io_timing_buffer_mod

pd_midi_input_quere_mod

I am not sure if I understand the description of your problem, though I am not sure if it matters as long as it has anything to do with SYSEX failure in Pd.

Are you running both those interfaces directly in Linux?

Also, what version of Pd?

I do have some general info about obtaining and or maximizing MIDI/SYSEX performance with Pd.

Linux and Mac platform Pd is partially functional with regards to SYSEX but to obtain full functionality requires some minor tweaks be made to the source code and compiling Pd from said source. Windows Pd has it's own problems with SYSEX and MIDI, for which I know of no current solution.

edit: misread the post, I think...