@jancsika it's not ~only~ that though. They are more like objects than gui elements.
mainly the inability to edit them in run-mode is the reason that they would basically be equivalent to a bang with a label (which internally can be used to "bang" the appropriate message)
@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.
@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 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)
@jaffasplaffa I think your biggest problem will be routing the info of the various parameters to the appropriate locations. I guess the way to do it might be to have a giant [route] with a counter, for each type of sysex? basically you need a state machine with a counter that counts how many parameters have been received, and changes the routing depending on the values of previous received values
if you want to do the 32-patch sysexs you will need to do some bitshifting of some of the inputs for a few parameters too.
tihs type of thing is really better accomplished in a text format I think, perhaps look into pdlua or py/pyext or pdjs.
if you use one of these you might be able to simplify things by having an array with the name of a recieve, so you can just count the parameters and send to an appropriate receive by reading the right value from the array.
another way to do it would be to have each receive follow a specific naming format (like $0-param0, $0-param1 etc.) and then look up the appropriate number in an array for the different types of sysex. Then you can just change the send name depending on which parameter is being sent using pd's built-in message formatting with $1 etc.
how did you do it with individual sysex parameters?
@Kosmas I think that unfortunately
[readsf~]only looks in either a relative path to the canvas or an absolute path. The way to do this is to create the appropriate absolute path from your relative path.
The easiest way to do this in vanilla is probably with $1 in a message box:
[symbol rec-1.wav( | [open /my/absolute/path/$1( |
edit: it seems like
[declare]should work for
[readsf~]but doesn't; might be a bug..
@lysergik you might want to mix some oversampling with an antialiasing method (like the BLEP method in J09.bandlimited.pd in the audio examples, or the wave table method of the bandlimited oscillators in the mmb library https://github.com/dotmmb/mmb. Incedentally it seems like serum does something similar but with mip-mapping http://www.mp3-tech.org/programmer/docs/resampler.pdf)
Unfortunately getting bandlimited fm is pretty difficult, I'd imagine you'd have to upsample at least 2x. I did find this when looking up BLEP tho http://www.willpirkle.com/Downloads/AppNote AN-11 PDSynthesis.pdf
@cfry in my library (shadylib on deken) I have some objects
[streamwrite]that read/record streams of data and store them as lists separated by "/". Then you can use
[stream-fromtext]to save them as text files. you need zexy for
[ekext/cup]too (though these can be replaced with vanilla alternatives). (the
[prepender]objects can be replaced by
[iem_prepend]from iemlib or a vanilla alternative if you just want to grab the abstraction & don't want to use the rest of the library)
@bluelight the super 6 has a samplerate of ~5 Mhz, so that probably isn't something you can emulate easily. (you'd have to upsample by a factor of ~100 at a base samplerate of 44.1 k!) Other than that, there are various tricks to minimize aliasing but you'll never get the flexibility that comes with just running at a very high samplerate in an FPGA.
serum does anti-aliased wavetable stuff with some kind of mip-mapping I think http://www.mp3-tech.org/programmer/docs/resampler.pdf (storing various numbers of octaves/harmonics), but to get anti-aliased hard sync would be more work, and the sound will never quite be the same.
It's also important to remember that anything you make in pd will be less efficient than the same thing written in c or c++. (and once you start adding lots of voices & gui that can become a relevant factor). but it's useful for fast development, ease of use, experimentation, and prototyping at the very least.
that being said it is possible to make polyphonic synths with low aliasing. here's one I made that I like the sound of (tho youtube messed up the sound w/compression)
use an additional
[tabread4~]to crossfade between the sounds too. I'd also recommend keeping the wavetable index a signal (then the fractional part is how much of the current vs. next wavetable).
you might have resolution issues with just using
[+~ ]for the wavetable offset due to 32-bit resolution, but I don't think you'll have much difficulty for normal wavetable sizes.
there was a library iem_dp that had a tabread~ that allowed a signal to be used for the offset, but I don't see it in deken now
my library also has
[tabread4hs~]which also has a signal inlet for offset (but uses different interpolation)