Dear List,
Is there for PD on Windows any possibility to have an oscillator bank with say 50 to 100 oscillators, that accepts a list of 50 to100 components to set/change the frequencies of this oscillators dynamically, possibly smooth with a line~ object? How can I best read in large amount of multichannel data, to conveniently control such an oscillator bank?
msgfile from zexy cannot read the following file on my PC:
1,2,3,4 7,6,5,4 3,4,5,6 9,8,7,6 7,6,5,4 2,3,4,5
I get the following error:
tried C:\Programme\pd\doc\5.reference\help-zexy\test.txt and succeeded error: msgfile_read: unable to open test.txt.
Any help very much appreciated,
Thanks
Florian Grond
Hi Florian
Florian Grond wrote:
Is there for PD on Windows any possibility to have an oscillator bank with say 50 to 100 oscillators, that accepts a list of 50 to100 components to set/change the frequencies of this oscillators dynamically, possibly smooth with a line~ object?
Yes, of course. You just have to build it ;-) I recommend making a single abstraction that you can reuse multiple times. For bonus points, you could use [nqpoly4] to dynamically create them at loadtime (instead of copy/paste x 100!).
How can I best read in large amount of multichannel data, to conveniently control such an oscillator bank?
I would look at [pack] and [unpack] as a way or creating compound messages consisting of several floats. Also, [msgfile] might not be the best thing to use to save and load values. I've had very good luck with [col] as a way of storing and retrieving information, especially paths to files in my own case. Other people also use [pool]. Frank Barknecht's set of Memento abstractions would be a good place to look as well, since it uses [pool] and OSC to save and load presets. Lastly, you might look into [matrix] or [matrix~] as a way of handling large amounts of control information for your oscillator banks.
best, d.
Hallo Florian, Florian Grond hat gesagt: // Florian Grond wrote:
Is there for PD on Windows any possibility to have an oscillator bank with say 50 to 100 oscillators, that accepts a list of 50 to100 components to set/change the frequencies of this oscillators dynamically, possibly smooth with a line~ object?
As Derek recommended, you should definitely look a the matrix objects for this. To see this approach in action: I used [mtx_*~] to build the operator matrix of the PDX7 V2 (http://footils.org/cms/show/51). It just has 6 oscillator operators, however as they all can modulate each other, even with that I have 36 multiplications going on inside [mtx_*~], which would be horrible to patch without the matrix object. (I can show you some details if you're at ZKM during LAC2006.)
[mtx_*~] can save it's settings using its own file handling routine, however I just dumped the matrices to a long list to be able to use it with Memento.
I guess you are aware that having 100 [osc~] objects running will already generate a significant load on your system, so you might also want to consider precalculating all partials, write them to a table and play this with e.g. [tabread4~]. Using more than just one table and [tabread4~] and crossfading the [tabread4~]'s whenever a table changes can help with fighting clicks in that situation, but the approach might not be possible at all depending on how quickly your partials may change.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 14 Apr 2006, Frank Barknecht wrote:
As Derek recommended, you should definitely look a the matrix objects for this. To see this approach in action: I used [mtx_*~] to build the operator matrix of the PDX7 V2 (http://footils.org/cms/show/51). It just has 6 oscillator operators, however as they all can modulate each other, even with that I have 36 multiplications going on inside [mtx_*~], which would be horrible to patch without the matrix object. (I can show you some details if you're at ZKM during LAC2006.)
Note that execution time of such a thing goes with the number of inputs times the number of outputs, so if there's some kind of organisation in the way inputs contribute to outputs, then you should cut the work into smaller parts, because if one of the smaller matrices is all zeroes, you can omit it completely and that's less CPU usage.
Note also that one of the two matrix multiplicators for signals is backwards (OTOH, from the perspective of its author, all other matrix multiplicators for pd are backwards...). This just means that one kind of object makes rows of the grid correspond to inputs, while the other makes columns of the grid correspond to inputs.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Fri, 14 Apr 2006, Frank Barknecht wrote:
Note also that one of the two matrix multiplicators for signals is backwards (OTOH, from the perspective of its author, all other matrix multiplicators for pd are backwards...). This just means that one kind of object makes rows of the grid correspond to inputs, while the other makes columns of the grid correspond to inputs.
for clarification: [matrix~] (from zexy<2.0) will get a vector of output-signals O^ from a vector of input signals I^ via the following equation: O^'=I^'*A this is a bit weird since in the scientific community this equation is usually denoted as: O^=B*I^ (both equations are the same if B==A')
however it does makes some sense (at least: it did for me :-)) in terms of the pd-patch (creation arguments of [matrix~] and how you connect cords to the inputs of the object)
anyhow: [matrix~] is deprecated, don't use it! use [mtx_*~] instead, which follows the scientific convention... the help-patches in the CVS are updated (one of the greatest drawbacks of [matrix~] was, that it had non-standard behaviour and there was NO help-patch at all....)
mfg.ads.r IOhannes
On Tue, 18 Apr 2006, IOhannes m zmoelnig wrote:
[matrix~] (from zexy<2.0) will get a vector of output-signals O^ from a vector of input signals I^ via the following equation: O^'=I^'*A this is a bit weird since in the scientific community this equation is usually denoted as: O^=B*I^ (both equations are the same if B==A') however it does makes some sense (at least: it did for me :-)) in terms of the pd-patch (creation arguments of [matrix~] and how you connect cords to the inputs of the object) anyhow: [matrix~] is deprecated, don't use it! use [mtx_*~] instead, which follows the scientific convention...
Science and math are full of contradictory conventions. You prolly have encountered little-endian polynomials by now, as well as big-endian polynomials. Matrix rows are top-to-bottom, but plane geometry is bottom-to-top. Modular arithmetic usually starts at 0, but matrix indices start at one. Row numbers come before column numbers if you're dealing with matrices, but we write points as (x,y).
I've known profs that bitched at each other because one wanted to write y=Ax and the other wanted to write y=xA'.
The result is that I don't care. All I want is a system that is internally consistent so that I don't have to look up the manual to figure out the order of things.
Btw, in [matrix~], where's the inlet for modifying the matrix's values? is it leftmost or rightmost? what is it with [mtx_*~] ?
it had non-standard behaviour and there was NO help-patch at all....)
When there's no standard it's normal to be non-standard.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
Btw, in [matrix~], where's the inlet for modifying the matrix's values? is it leftmost or rightmost? what is it with [mtx_*~] ?
in order to be consistent: [matrix~]'s "matrix" inlet is on the right-side (it is not rightmost, since that is the fade-time, but it is 2nd rightmost): the object does I^*A [mtx_*~]'s "matrix" inlet is the left-most inlet: the object does A*I^
it had non-standard behaviour and there was NO help-patch at all....)
When there's no standard it's normal to be non-standard.
true. but half of my institute nudged me because of [matrix~]'s behaviour, so we finally decided to change it in order to satisfy them....
mfg.as.dr IOhannes
On Tue, 18 Apr 2006, IOhannes m zmoelnig wrote:
Btw, in [matrix~], where's the inlet for modifying the matrix's values? is it leftmost or rightmost? what is it with [mtx_*~] ?
in order to be consistent: [matrix~]'s "matrix" inlet is on the right-side (it is not rightmost, since that is the fade-time, but it is 2nd rightmost): the object does I^*A [mtx_*~]'s "matrix" inlet is the left-most inlet: the object does A*I^
ah ok. In GridFlow, [#inner] also uses left to mean left and right to mean right as in the ordinary matrix product. However I wouldn't be able to make a swapped version mean anything because I'm often not multiplying vector*matrix, so e.g. replacing the current image*matrix product by a transposed matrix*image product would require transposing each image twice (instead of zero times) because the vectors are pixels and the channels of the pixels are the last dimension. ([#inner] has to be consistent with the standard definition of tensorial contraction)
When there's no standard it's normal to be non-standard.
but half of my institute nudged me because of [matrix~]'s behaviour, so we finally decided to change it in order to satisfy them....
aaah... peer-to-peer pressure... how many kilopascals was it like?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
the help-patches in the CVS are updated (one of the greatest drawbacks of [matrix~] was, that it had non-standard behaviour and there was NO help-patch at all....)
Hooray!!
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
derek holzer -
Florian Grond -
Frank Barknecht -
IOhannes m zmoelnig -
Mathieu Bouchard