DSP Robotics Support

I would just like also to add that a spline-based control system would be SO nice to have, having read trog's comments.

When I was playing with trog’s thing I made an exponential decay and it did take time to get the several slope segments right. In fact it needed a lot of nodes to sound smooth (especially so for a filter sweep) and, as trog said, to change the slope after would have been a lot more work.

My praise for trog’s work was well justified I think. I marvel at his talent, but that doesn’t mean the spline thing has been displaced, so go for it Tom!
I can’t wait to see it!

Cheers

Spogg

Spogg wrote:...so go for it Tom!

Who's that "Tom"?

tulamide wrote:

Spogg wrote:...so go for it Tom!

Who's that "Tom"?

Oh I see. You've forgotten your name then?

the wavetable osc is owesome Trog! ty- !

Thanks, nix; I'm glad you like it! As I said to Spogg, I'll post it in its own thread once I have the sync options etc. added in and the stream code optimised to ASM. I just want to get the little Ruby API that I promised tulamide finished first. In fact, that should go hand-in-hand with improving the wavetable-osc, as tulamide's splines would be a great way to adjust the cross-fading curves between wave segments; oscillators and modulators would then have almost the same GUI.

Thanks trogluddite, this is very useful code and I find the cencept very interesting.

I remember looking at the arpeggio sequencer made by Nix with the same amount of awe. There's a lot of potential. But, I am curious would there be an issue in faster than real time for bouncing?

Thanks,
Robert

wlangfor@uoguelph.ca wrote:But, I am curious would there be an issue in faster than real time for bouncing?

Good question!

Experience suggests that it may depend on the VST host. The stream code itself shouldn't present any problems, and would certainly be fine if the tempo "clock" is free-running (it's all calculated by counting incoming samples in that case). But if the tempo is slaved to the VST host, it will depend on whether the host passes Tempo/PPQ signals correctly when it's rendering off-line. I have a vague memory that we've had problems with that before in some hosts (a bit like the hassle with FL's non-standard interpretation of PPQ "quarter-notes").

I've made similar "PPQ synced" modules before (e.g. my SyLFO), which have always rendered fine in Reaper (my usual DAW of choice); but in practice, having a bunch of testers try out all of the different hosts is the only way to know for sure. I also haven't tried out the Alpha's new double-precision PPQ/Tempo/etc. primitives, which should allow much tighter timing, especially on long songs. I haven't got my head around what DSP/ASM changes DP and/or 64-bit might require yet, so it may be some time before I have any code available to test those out.

@trog You really shouldn't do this!

Each time you post in this thread I think "that's it, now comes the version I wait for". I have a tender soul, trog. My poor aching heart!

pulls at the ole heart strings ...

I'm weary of ruby, but it would be ideal for such an operation. I'll look at the examples and try to learn what I can. It's an exciting project Tulamide.