From the original SynthMaker forum (2004–2014), with its members’ names and dates.
attic ·
Do the tick25 or 100s get their pulse from the same source or is it independent per module? Is it better to wire your schematic to access the tick from a single module or is it not that big a deal to have multiple tick sources as they get their signal from the same source, Cpu wise I mean?
Also if any body knows about this? Sample Player/Looper Zoom? I realize that maybe a big question, or possibly something I should already Know?
infuzion ·
I have not tested it, but I assume each Tick will run on its own thread, ie not be in sync. If you want to make sure for them to be in sync use a master Tick & use wireless connectors.
attic ·
I have not tested it, but I assume each Tick will run on its own thread, ie not be in sync. If you want to make sure for them to be in sync use a master Tick & use wireless connectors.
Thanks for the answer. The tick components are based on windows timers, something I missed reading in the manual so I guess they would have their own thread always and that means extra cpu for every tick component used. I guess this was a dumb question to ask. Ask less... read more! .... Bangs head against keyboard.
I just finished rereading large chunks of the Components Reference trolling for ideas on some of my builds and realized something else that should have been obvious, the Save Wave component is only mono! I hadn't been to the point where I needed it yet and just assumed that it would handle stereo. That really frickin sucks. 😠 I hope the RUBY thing makes it into SM but even with RUBY in place I'm starting to question what corner of Dsp land the OutSim developers come from. There are some obvious reasons to feel frustration. Am I missing something is stereo wav save out possible? Edit I have to be missing something right?
Edit Looks like I don't understand I found this in another thread.
Yep - you can you use "Mono to Graph" into "Float Array to Mem" into "Save Wave" (this last one is an R&D component). You can save a stereo wav, but I can't remember what the trick is for that.
The threads here Own Voice Recording So maybe I will find the info, but feel free to jump in and save me the time.
infuzion ·
attic wrote: I have not tested it, but I assume each Tick will run on its own thread, ie not be in sync. If you want to make sure for them to be in sync use a master Tick & use wireless connectors.
Thanks for the answer. The tick components are based on windows timers, something I missed reading in the manual so I guess they would have their own thread always and that means extra cpu for every tick component used. I guess this was a dumb question to ask.
Well, your 2nd question is still unanswerable with out testing the OSM, since the real answer is "It depends". Sometimes it is good to have multiple threads (if my assumption is correct). Also if you have only 1 Tick25 for the entire OSM, then when a single tick is sent, it has to travel & affect multiple parts of your OSM, one part at a time, which may or may not be "better". So it is smart to ask. Also smart to read 1st 🙂
attic ·
Also if you have only 1 Tick25 for the entire OSM, then when a single tick is sent, it has to travel & affect multiple parts of your OSM, one part at a time, which may or may not be "better".
Good answer, that I think explains what I have been seeing. I can work with that. Now a little reorganization and see where my cpu ends up at. Thank you for that. I suppose I should read Troggy's trigger tutorials for the 11th time.
trogluddite ·
Yes, I can confirm what infuzion says about trying to 'stagger' ticked triggers where possible.
In previous version of my Loopa plugin, all screen redraws (and the area calculations etc.) were driven from a single 'heartbeat' timer. On this plugin it is quite normal to have 9 audio meters running and a dozen or so controls animating to show the built in automation. What I have done now is to take the 'heartbeat' ticks (useful as the user can select the frame rate), but to delay the triggers used by the various redraws by different amounts. As an example, with animations going full pelt, the peak CPU load on Task Manager went from 15-18% down to around 9-12%. Of course the total amount of processing over time is going to be the same, but smoothing out the peaks should still lead to a useful increase in the amount of 'stuff' your DAW will run simultaneously. I also do a similar thing with hopped assembly - you can 'stagger' the samples on which various hops get executed for a similar reduction in peak load.
attic wrote: the Save Wave component is only mono!
I think that this has changed recently. IIRC, the old R&D 'Save Wave', had a fixed bit depth format, but did have a mono/stereo boolean input. The new 'official' version adds the extra formats, but seems to have lost the mono/stereo switch. Possibly it autodetects whether the 'mem' is mono or stereo automatically - the documentation doesn't mention this though.
But even if stereo 'mem's are auto-detected, that could still leave you with a problem - you can create a stereo 'mem' and record to it using the 'Wave Write' primitives, but the 'Float Array to mem' only ever creates a mono 'mem' . AFAIK there's no simple way to take two mono arrays (left and right) and interleave them to form a single stereo buffer (or duplicate a mono channel for 'stereo conversion'). The only way I can think of would be to use a counter to step through the two mono 'waves' and record each pair of samples to a new stereo mem using Wave Writes (i.e. a real-time 'bounce down' - SLOW!)
And yes, you're right, the way that 'mem' and audio files are currently handled is not good enough for software designed specificaly for DSP/music.
infuzion ·
trogluddite wrote: What I have done now is to take the 'heartbeat' ticks (useful as the user can select the frame rate), but to delay the triggers used by the various redraws by different amounts. As an example, with animations going full pelt, the peak CPU load on Task Manager went from 15-18% down to around 9-12%. Of course the total amount of processing over time is going to be the same, but smoothing out the peaks should still lead to a useful increase in the amount of 'stuff' your DAW will run simultaneously. I also do a similar thing with hopped assembly - you can 'stagger' the samples on which various hops get executed for a similar reduction in peak load.
That's a neat staggered-redraw trick! I'll have to figure out how to stagger hops sometime...
BTW, each Tick primitive starts each own thread; that is how the "De-threader" works.
lesobrod ·
Being reading this post some idea comes to me. If Ticker is like a heart, how even,uniform it "beats"? So I make some schematic for measuring intervals between successful ticks of Ticker100. Here is histogram of analysis. It looks very strange.
Maybe I do something wrong; should be about 1 average value (?)
infuzion ·
lesobrod wrote: If Ticker is like a heart, how even,uniform it "beats"? So I make some schematic for measuring intervals between successful ticks of Ticker100. Here is histogram of analysis. It looks very strange.
Should be strange uses Window's timers, which are unpredictable. Other GUI-languages like MAX/MSP have the same timing issue, so don't worry too much.
I did find in a heartbeat test by hooking it up to Time, dividing it by what Frames Per Second I wanted, then doing some trigger/value maths, I got a decent average FPS in the 12-25FPS range.
lesobrod ·
infuzion wrote: Should be strange uses Window's timers, which are unpredictable. Other GUI-languages like MAX/MSP have the same timing issue, so don't worry too much.
Well, thanx, but all things have measure and I try to find how much it unpredictable. I hope Thick100 is not a noise ))) so my first osm was wrong. So many elements produce randomness. Your idea with Time primitive is great 😀 Using it I make follow histogram:
So Ticker100 is predictable enough 😉 Only less than 0.1% values out of narrow {0.015..0.016} range. But why this range around 0.015 sec, not 0.01 sec?!! This means that timer stable, but has wrong period. Maybe its only on my comp?
infuzion ·
I think SM looks for a tick when ready. So, might not be ready always the same time. Try pegging the CPU while doing the test (eg view a large DVD movie, run a 3d program, ect).
attic ·
I think you are measuring stuff that will change on every machine but cool to see an example. I think the results will really be dependent on the specs of ones PC? Although I do wonder what the average would be out of maybe 15 or 20 different PC's.
It gives me a funny thought. If you measured the length of intervals and used that to generate what notes in an array you would allow to play, you could use the inaccuracy of windows timer's to generate some semi-random music from the inaccuracy.
Well off to put 300 timers in a schematic for the most random mix I can generate before I crash my machine.
lesobrod ·
attic wrote: It gives me a funny thought. If you measured the length of intervals and used that to generate what notes in an array you would allow to play, you could use the inaccuracy of windows timer's to generate some semi-random music from the inaccuracy.
Your thoughts are very close to mine ...and to the edge of madness, be carefull! 😈 ))) I've always got RandomMusic.osm but feel shy to post such stuff on International Forum 😇
And immediately after I saw this
Developers wrote: The component uses a Windows timer and therefore cannot be relied upon to be accurate.
idea "inaccuracy of windows => source of noise in SM" appeared in my morbid head.
As all here probably know, all "random" numbers from any algorythm are quasi-random. There are many software for detecting real chaos from comp - variations of CPU temperature, RPM of hard disk, memory allocation, mind scanner )))))) etc. But to put it into SM project is difficult enough; so to use some internal<->windows errors is very good idea.
So..some barriers to total live chaos still persist ))) As you seen, only 4 differents "random states" can be taken from Trigger100 period in ms. And I don't know at all how to get Stream noise from inner SM inaccuracy ... but it's my crazy dream!
trogluddite ·
infuzion wrote: That's a neat staggered-redraw trick!
It pays to be a little careful with it though - I have been using trigger delays (timer with output looped to stop input) with a range of about 5-15 ms (nominal). Too long, and the next heartbeat will arrive before the timer has elapsed, causing it to reset - and it will never generate an output tick. No doubt very heavy CPU loads could cause the same problem. Too short and... ...hmmm, not really sure why , but it seems to cause issues for me, including lock-ups on my slower machine. But this could just be an effect of my schematic; maybe best not to read too much into it until tested better.
infuzion wrote: I'll have to figure out how to stagger hops sometime...
mov eax, ecx; and eax, {hop value - 1} cmp eax, {offset from normal hop time - must be <= the 'and eax' value} jnz {label}
No code equivalent. But for folks who don't write assembly, you could copy and paste the text from a Code string output into an assembly box. Then, look for the lines like mine above - and edit the line 'cmp eax,0' that will be there already.
lesobrod wrote: Maybe its only on my comp?
No, this is perfectly normal behaviour for the Windows Times used by SM, it will vary a lot with CPU load. About 60Hz for a tick100 seems about normal, even when there is little CPU stress. For anyone that is interested - there is some more discussion, and also a 'timer variation measurer' module in my old oscilloscope example.. For that module, I even had to disable 'live' screen updates to stop it from affecting its own measurements too much.
@lesobrod & attic Getting the ticker 'Faults' to do something interesting!?!! - I really like your "making a virtue out of necessity" style! 🙂 Mostly it is just one of our favourite things to bitch about
Only trouble is - what are you going to do if they ever fix the trigger system - you will have to send a bug report to OutSim to say that they broke your chematic!! 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker