Please change the tick signal to hopped Sample clock

Disco_Steve · 21 Oct 2010

arr the joys of this question. the age old question of SM, if only I could work out a workaround I could do all the stuff I want to do with FFT's I can only guess its hard as it is yet to have been done yet by the SM team. and I doubt it will ever come along as you can do it in blue if your really comited.

if you want to make a sequencer you will have to do it in blue. it will be a pain, but it will work! however you will most likely land into problems with running out of count in your floats, so you will need to re set the clock and count clock blocks. you will have to hard wire a fixed number of tracks and making them take dynamic input will be fun fun fun (NOT!) at a guess you will have to hard code every posible situation, and then let the users just select the ones they want. so you would have to limit each track to X number of audio clips, and X trracks. each clip would have to sit inside a module, and within that module would have to be a coppy of all the clip editing you would want such as gain length crop fade etc etc.

(I might be compleatly wrong on how to make a sequencer in Sm, other users use SM for other things than DSP which is all I use it for really)

if you want to make a sequencer i would greatly recomend C++ unless your just doing a midi sequencer then I would sugest c# as ultimate extreem performace wont be nesasary. adn C# just does 'everything' for you!

good luck in all your SM'ing

Steve

datsound · 21 Oct 2010

I d like to make all the modulation and control logic in green lines, sequencer times, Low frequency oscillators etc. i havent tried a sequenced synth in SM but it would be a pretty high learning curve if i have to learn the blue lines. there are good hopped ASM lfo's but it is difficult to add features to them in ASM and then all the calculations to the lfo signal cant be in green lines.

It would be brilliant if you could do FFT with green control lines also, for the moment i didnt know there were even blue lines so that is quite a surprise!

i wonder how they work out the features list for the next versions... pretty please synthmaker 😀

MichaelBenjamin · 21 Oct 2010

for now you can safely forget about doing it in green if you want precise and predictable timing. green timing ranges from "sounds like its synced" to "small hiccups" to "randomly weird" to "just awkward" depending on what your computer is doing else and how earths magnetic field is currently fluctuating. as disco steve said, do it in blue, and check out tomc dynamic hop at the wiki, it should not be much more complicated than in green. just get a configurable bang pulse in dynamic hopped asm, and do the rest in blue code.

datsound · 22 Oct 2010

really i am not doing a sequencer, it is just to say that FFT, sequencers, LFO's, Arpeggiators, drum machines, sample mash control routings, all these things are only possible with synthmaker if they change the green lines from CPU clock to Hopped sample clock in the SM system core.

like green line timed by 44.1/ 128 would be fantastic. as long as there was a sample rate status module we could even keep any ramps and counters balanced with dividers. ty

Mo · 22 Oct 2010

It is possible already using code and the PPQ module. You get very precise timing.

datsound · 22 Oct 2010

PPQ seems ok for sequencer control, but it still audio and so quite processor hungry. all the green lines should really be clocked to hopped samplerates rather than ticks, to make every element of the modultion and logic control green and bit accurate rather than making them in stream mode that uses 128 times more processor.

Mo · 23 Oct 2010

You can easily hop stream processing to reduce cpu consumption. Green is made to have lower priority for the GUI part and where you don't need sample accurate timing and thats why it's more easy on cpu. If green was sample accurate it would be the same as the already existing stream. BTW, we could need a stream input for the midi event to make midi out sample accurrate.

datsound · 23 Oct 2010

i understand that CPU tick can be the absolute easiest option on the processes, and it is entirely adequate for GUI elements.

If the green line was 1/128 of the stream processing load, and just a sample accurate 1/128 line, then it would be useable for all the sequencer, modulation, lfo, etc tasks, and wouldnt take as much as stream as it would be just 128 of the FP ops.

The gui priority in windows is also managaed by the redrawing process, which you can adjust with "priority for background processes"

say that green line is maximum 200 mhz, varying wildly all over the place. if you divide 44.1 by 256 you get 180 mhz, at 1/256 amounts of operations that stream is doing, but closer to sample accurate than green line.

Mo · 24 Oct 2010

The problem would be you interrupt the stream signal on heavy tasks in green if you give it the same priority. I don't think you can make it sample accurate in 2. priority as green processing waits for stream to process first and on heavy cpu load green stops and wait for stream to process. Just make sequencing in hopped stream and you got 1. priority sample accurate timing.

TheAudiophileDutchman · 24 Oct 2010

Mo wrote: BTW, we could need a stream input for the midi event to make midi out sample accurrate.

+1 That's an excellent idea! 🙂 (Midi normally is not fully sample accurate though)

datsound · 24 Oct 2010

Mo wrote: The problem would be you interrupt the stream signal on heavy tasks in green ... priority sample accurate timing.

maybe, it depends.

if you use 1 percent CPU from faster green lines you save 3-7 percent on stream rate P-F and midi note conversions etc.

2 stream P-F modules cost you 256x calculations. 2 plus and minus (unison detune) onto the incoming "stream midi pitch" cost you another 256. so in just 4 stream modules that should normally be on a green hop line, you miss out on 512 MODULES you could plut in a hopped green mode.

The Green line would receive a 1/128 samplerate trigger at high priority, which is only 1 processor instruction. and the calculations could be queued and executed at a lower priority than the actual sample timed instruction, if you felt it was essential.

Besides, i wonder how reaktor is able to manage tick that is sample accurate +/- 2ms, but takes 100th of the processing?

is it worth giving up 1/128 of your processor for a way of timing your synth that is accurate? if you can save much more by avoiding stream midi note and trigger lines?

datsound · 26 Oct 2010

TheAudiophileDutchman wrote: Mo wrote: BTW, we could need a stream input for the midi event to make midi out sample accurrate.

if it is hopped by 128 it is max 2.7ms latency extra on the midi data.

trogluddite · 26 Oct 2010

Mo's suggestion of the sample accurate MIDI triggering is in the right direction - PLUS a 'Hopped Module' - i.e. A module container where any stream components placed inside it would be hopped. This gets around the problem that hopping can currently only be used by those who are fluent in coding and assembly.

Accurate 'green' timing is not the solution - the 'green' system is not designed to lower processor load by simulating 'hopped code' - it's primary advantage is that is uses NO CPU AT ALL when there are no triggers - so that we can make extremely efficient GUIs that don't load our processors when we are not interacting with them. It is designed purely to make infrequent, unpredictable events easy and efficient to handle.

Using repeated fast triggers eventually leads to HIGH CPU load because of the CPU overhead of keeping track of all the triggers - even sample rate /128 is 344 triggers per second, and using the green triggering system constantly at this rate would actually not be CPU efficient at all - using hopped streams would blow it out of the water because 'blue' has no triggers to keep track of.

I'm not saying that we don't need enhancements to make sequencing etc. work properly - of course we do, I agree with you all wholeheartedly on that point. But the answer does not lie in the green trigger system, keep that for the GUI programming that it is intended for. What we do need are enhancements to the Stream system to make these things easier to implement (i.e. Stream to MIDI, Stream equivalents of green maths modules, easier hopping, stream FFT etc.)

Tzarls · 26 Oct 2010

I´ve asked for this before (and if I recall correctly, so did Oddson), but here it goes again - a good solution for all this accurate triggering (for MIDI of any other kind of event) would be a stream "bool to true" and "bool to false", that fires a green trigger when the boolean condition is met. That way we shouldn´t have to wait for a new green event system or for modifications to existing primitives.

MichaelBenjamin · 26 Oct 2010

no, not green triggers. green triggers suck. they are not exact whatever you do, even if its fired from a stream primitive. better would be a system that spawns midi notes/voices directly with stream input.

Tzarls · 26 Oct 2010

Well, I´ve never had problems with green triggers if fired from the outside world (in other words, not fired by the tickers of timers).I see no reason for them to be not accurate, aside from the fact that green lines might have lower priority. Hey! Maybe add the option to set green priorities?

Anyway, I still want said primitive. 🙂

gregh · 4 Mar 2011

I have not been here for a long time - but is this problem with event timing for sequencers still not fixed? I'm thinking here in terms of making algorithmic music generators where timing between components must be correct. thanks, gregh

Mo · 4 Mar 2011

gregh wrote: I have not been here for a long time - but is this problem with event timing for sequencers still not fixed? I'm thinking here in terms of making algorithmic music generators where timing between components must be correct. thanks, gregh

The only problem concerning sample-accuracy, would be a midi output, as there's still no stream trigger input for the midi event primitive.

gregh · 4 Mar 2011

how are you keeping things accurate internally? Please excuse my probably poor terminology as I haven't look at SM for qutie a while, but when I was using SM at the beginning I used green data to trigger events internally. This was necessary to be able to perform various computations and logical operations. unfortunately that system was not accurate enough in it's timing. I would love to know of any developments to improve that

Mo · 4 Mar 2011

You'll need to use stream/code . You can use sample position or ppq for host synchronization and sequencing. See the trance-gate example: Trance Gate

gregh · 4 Mar 2011

thanks. I'll check that out