• nuromantix

    Yes I think you will soon discover that the sounds made by crossfading between 2 arbitrary waveforms are not all that exciting. You can add interest by having a few layers of different waveforms crossfading at different rates but it's always quite bland sounding.

    posted in technical issues read more
  • nuromantix

    That's right. Crossfading between 2 waveforms is what you get in synths like Yamaha TG33, Prophet VS, and the Seiko ones. PPG stuff and Ensoniq stuff is more complicated. As far as I know, the PPG ones didn't crossfade at all, they just switched waves at the beginning/end of the next cycle (when the waveform is at zero so there's no click).

    There are lots of ways to get from A to B as far as changing between two waveforms go. Consider the change between a sawtooth wave through a resonant filter. As you open and close the filter, the sound changes. Crossfading between samples of "fully open" and "fully closed" would not get you even close! There are other interesting "morphs" between sounds that you can do with wavefolders with additive techniques, or with acoustic instruments, that cannot be emulated by simple corssfading, so that is where larger wavetables come in.

    So it just depends what you want to acheive!

    posted in technical issues read more
  • nuromantix

    Yes I get the feeling the delays are OK but [realtime] isn't!

    posted in technical issues read more
  • nuromantix

    Hmmm a mystery.

    posted in technical issues read more
  • nuromantix

    Thank you.
    But why in the tests above, with a positive value for the delay time of the [pipe] does it seem to fail to delay the input quite often?
    ie. with a delay value of 9 we see realtime delays of 10 or 11ms usually, but sometimes less than 1 ms.

    posted in technical issues read more
  • nuromantix

    My next question is: why is pipe so unreliable?
    Using my tests and yours, something like [pipe 9] returns a realtime value between 10.3 and 11.3 most of the time, and I guess that the extra 2ms is caused by the rest of the patch.
    But about 1 time in 5, the value returned is close to 0.
    Why is that?

    posted in technical issues read more
  • nuromantix

    So the spigot is quicker! Thanks for your help. That was the result I got too having just done my own test while I awaited your reply.

    posted in technical issues read more
  • nuromantix

    @weightless
    in fact I am sure because your patch always returns a result of 0.002 or 0.003 even if you set del to high values!

    posted in technical issues read more
  • nuromantix

    @whale-av
    I'm sorry, I don't understand your post, can you explain more simply?
    thanks!

    posted in technical issues read more
  • nuromantix

    @weightless
    either I am misunderstanding how [realtime] works or your patch is wrong.
    I thought you bang the left input to reset the clock and then bang the right output to get the time at the end of the process, like this:

    pipetest1.pd

    ...or am I mistaken?

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!