[PD] tabosc4~ and table byte reallocation

[mami music]

Hi all and thanks

2010/1/26 cyrille henry <ch at chnry.net>

>
>
> mami music a écrit :
> https://mail.google.com/mail/?shva=1#inbox/1266c7380e4f9473
>
>> Hey cyrille thanks for your answer. But it didn`t quite work.
>> Im dinamicaly feeding the table with a signal,
>>
> hum,
> you can sync this with bang~


yes yes!!! [bang~] was the object i was missing.


>  so the 256th sample of the signal changes at block speed and the writing
>> of the 257th and 258th sample is done at control speed. (please check
>> attached patch)
>>
> if you change the table use by tabosc~, you should expect to have some
> click anyway.
> moreover, your table did not loop, so don't exepct a clean sound...

Thats right. It doesnt loop all the time. Only when the carrier diverges in
small amount from an intire multiple of the carrier frequency, but that is
FM matters, not [tabosc4~].


>
>
>  I used an [until 44] to see if i could make up for the differences in the
>> signal time, bit still not working
>>
>> Ill check the nusmuk external to see how it works, but definitely would be
>> glad to make it in vanilla.
>>
> i can understand that.
> but delay~ is not in vanilla.
>
wao wao!!! had always used it without checking its origin in the help
file.... you ar absolutely right!!!


Another question rises now:
When the signal inside the array cant loop at the block~ frequency is there
a windowing method any would recomend to try to smooth things out (obviously
there would be distortion).
Maby having two [tabosc4~] one with phase shift of 180 degrees in relation
with the other with some sort of windowing... but i guess that would be
equivalent as making the blocksize bigger....

Thanks again!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100126/e8f07f6e/attachment.htm>