flies

so i'm building a simple wavetable oscillator where you draw the wavetable

with a multislider. Right now i'm using cycle to read the buffer, but

multislider has a max number of sliders of 256, but cycle wants to oscillate

over 512 samples. The ideal solution for me would be a multislider with 512

* just repeat the 256 multislider values to make 512 values for cycle to

the second option would be nice cuz i could use the interpolation options

for wave~, but i'm not sure how to make sample-accurate loop points for

so i'm building a simple wavetable oscillator where you draw the wavetable
with a multislider.  Right now i'm using cycle to read the buffer, but
multislider has a max number of sliders of 256, but cycle wants to oscillate
over 512 samples.  The ideal solution for me would be a multislider with 512
sliders, but that's not crucial.

possible solutions:
* just repeat the 256 multislider values to make 512 values for cycle to
read (and halve the nominal frequency)
* use wave~

the second option would be nice cuz i could use the interpolation options
for wave~, but i'm not sure how to make sample-accurate loop points for
wave~

multislider-wavetable-osc

You could use waverform~ or even function (or ej.function.js with curves!).

The 256 limit is not due to multislider. In this case it is "zl iter 1" with the limit. BTW "iter" would do in this case and I checked and this also has the historic 256 limit in Max 4.6 but NOT in Max 5 ("zl iter 1" still has the 256 limit in Max 5 however).

Another way round it is to read the sliders one by one using the fetch message:

On 19 juil. 08, at 22:58, Martin Robinson wrote:

> You could use waverform~ or even function (or ej.function.js with 

> The 256 limit is not due to multislider. In this case it is "zl iter 

> 1" with the limit. BTW "iter" would do in this case and I checked 

> and this also has the historic 256 limit in Max 4.6 but NOT in Max 5 

> ("zl iter 1" still has the 256 limit in Max 5 however).

Nope. in Max 5 zl is limited to 32k items, you need to specify the 

number of maximum items as first argument:

> Another way round it is to read the sliders one by one using the 

Another convenient way to store a list in a buffer is to use [mxj 

> You could use waverform~ or even function (or ej.function.js with  
> curves!).
>
> The 256 limit is not due to multislider. In this case it is "zl iter  
> 1" with the limit. BTW "iter" would do in this case and I checked  
> and this also has the historic 256 limit in Max 4.6 but NOT in Max 5  
> ("zl iter 1" still has the 256 limit in Max 5 however).

Nope. in Max 5 zl is limited to 32k items, you need to specify the  
number of maximum items as first argument:

> Another way round it is to read the sliders one by one using the  
> fetch message:

Another convenient way to store a list in a buffer is to use [mxj  
ej.l2buffer].

Quote: Emmanuel Jourdan wrote on Sat, 19 July 2008 22:11

----------------------------------------------------

> Nope. in Max 5 zl is limited to 32k items, you need to specify the 

> number of maximum items as first argument:

Ah. That's an improvement in Max 5 I hadn't noticed in the docs (and didn't bother to check in zl help). I probably wasn't paying attention. So are all list ops now based around a maximum of 32k items?

Quote: Emmanuel Jourdan wrote on Sat, 19 July 2008 22:11
----------------------------------------------------
> Nope. in Max 5 zl is limited to 32k items, you need to specify the  
> number of maximum items as first argument:

Ah. That's an improvement in Max 5 I hadn't noticed in the docs (and didn't bother to check in zl help). I probably wasn't paying attention. So are all list ops now based around a maximum of 32k items?


On 20 juil. 08, at 17:28, Martin Robinson wrote:

> Ah. That's an improvement in Max 5 I hadn't noticed in the docs (and 

> didn't bother to check in zl help). I probably wasn't paying 

> attention. So are all list ops now based around a maximum of 32k 

in theory yes. A few objects like mtof/ftom/atob/dbtoa can also take a 

> Ah. That's an improvement in Max 5 I hadn't noticed in the docs (and  
> didn't bother to check in zl help). I probably wasn't paying  
> attention. So are all list ops now based around a maximum of 32k  
> items?

in theory yes. A few objects like mtof/ftom/atob/dbtoa can also take a  
list as intput now.

Op 20-jul-08, om 18:08 heeft Emmanuel Jourdan het volgende geschreven:

> On 20 juil. 08, at 17:28, Martin Robinson wrote:

>> Ah. That's an improvement in Max 5 I hadn't noticed in the docs 

>> (and didn't bother to check in zl help). I probably wasn't paying 

>> attention. So are all list ops now based around a maximum of 32k 

> in theory yes. A few objects like mtof/ftom/atob/dbtoa can also take 

> On 20 juil. 08, at 17:28, Martin Robinson wrote:
>
>> Ah. That's an improvement in Max 5 I hadn't noticed in the docs  
>> (and didn't bother to check in zl help). I probably wasn't paying  
>> attention. So are all list ops now based around a maximum of 32k  
>> items?
>
> in theory yes. A few objects like mtof/ftom/atob/dbtoa can also take  
> a list as intput now.
>
> ej
>

===========
Eddy Deruwe
Hopstraat 71
1000 Brussel

Tel: 02/5025670
GSM: 0495/466675
E-mail: eddy.deruwe@skynet.be
Skype: eddy.deruwe
=============================


Not sure if Emmanuel supplied this in his Max5 patch earlier (haven't checked), but here's a very simple method using multislider --> listfunnel --> peek~. 512 elements is no problem this way. But you could always use the mxj equivalent to zl group [mxj list.Group] for larger lists.

Not sure if Emmanuel supplied this in his Max5 patch earlier (haven't checked), but here's a very simple method using multislider --> listfunnel --> peek~. 512 elements is no problem this way. But you could always use the mxj equivalent to zl group  [mxj list.Group] for larger lists.

multislider wavetable osc