trogluddite wrote:A float changing at sample rate is a stream. The green floats could never run at anything like that speed because of the overhead of passing the triggers through the schematic (to calculate which calculations need calculating - if that makes sense?) - your CPU would melt down!
Code is the only way to go - a code module is executed at sample rate by definition.
The limitations this imposes on MIDI and the GUI are well known, but unavoidable at the moment - the division between sample rate streams and 'run on demand' green/GUI is part of what makes SM relatively user (and CPU) friendly - IMHO, the way this opens up VST design to amateurs is a key point of SM. To have the kind of power/flexibility available to people like Native Instruments, there's nothing for it but to program in C++/ASM.
When a stream changes I want to send out a MIDI note at that point, with no greater audible latency than if I had hit a key at that same point - which is hardly asking much I feel.
So a signal "heartbeat" is the way to go.
brokebust wrote:When a stream changes I want to send out a MIDI note at that point, with no greater audible latency than if I had hit a key at that same point - which is hardly asking much I feel.So a signal "heartbeat" is the way to go.
That could not work, because the signal could change at a point that was not on a "beat". If you need me to explain the issue again in more detail I can.
Either way, still no solution!
MegaHurtz wrote:The signal will never change on beat..
oddson wrote:And now that's the final word on the issue and we'll all agree never to speak of it again even after it's fixed.
MegaHurtz wrote: Unless you have a supermind that can detect changes in image above 24fps. Wich we dont have. The slower ticker will suffice.
Users browsing this forum: No registered users and 1 guest