WTimer broken in exported VST's...

jorge · 18 May 2005

Shifrin wrote: It appears that the WTimer isn't working in VST's. The new 'funky' scope in the example synth doesn't show when it is saved as a VST and loaded into my host (EnergyXT). I tried a few other simple schematics with WTimers triggering graphic events - working in SM, not working in exported VST's.

Any chance this will get fixed?

Yeah, I noticed that too. I'll try to fix it soon and also to create a custom timer that lets you specify the time in ms.

lalo · 18 May 2005

jorge wrote: Yeah, I noticed that too. I'll try to fix it soon and also to create a custom timer that lets you specify the time in ms.

or in samples?

hard to decide...if with ms it should have a trick to deal with different sample rates ...so maybe sample is better and the the user will do the calculation from the SR reported by the host to the plug

opinions?

lalo

Shifrin · 18 May 2005

That sounds great jorge, as for the ms/samples question - I'm easy! Either would be good for me.

Shif.

jorge · 18 May 2005

lalo wrote: or in samples?

hard to decide...if with ms it should have a trick to deal with different sample rates ...so maybe sample is better and the the user will do the calculation from the SR reported by the host to the plug

opinions?

I'd there's two types of useful time events:

1 - events generated by windows like from the WTimer component that are generated on a separate thread from the sound processing. These events are not very precise, certainly not sample precise but they're very windows friendly so that even if your computer cant cope with the rate of events, at least it doesnt hang. In this case the time between events should be specified in ms. Although they're not very precise they're more than precise enough for Midi, sequencers, GUI refreshes, automation, animation etc

2- events that are generated from the sound processing thread and are sample precise, these events would be specified in number of sample. The problem with giving total freedom to generate these kind of events from the code component is that it would allow the user to generate them too often which could easily hang the computer. For example having 44100 green triggers per second would most probably hang the computer. That's why there isnt yet a PolyToTrigger kind of component. I think the solution might be to make these events go through an OnIdle stage that only lets them pass through if the computer can handle it, but then you lose the sample precision once again. I think with things triggered by poly sound it's better to try to keep it poly and not convert to the much slower green triggers. Another probably better solution is to create a new white PolyTrigger type as part of the compiled code. At the moment there's PolyBoolean which can also be used to trigger poly code at sampling rate.

lalo · 18 May 2005

yep, you're right jorge... i didn't think about cpu cost 🙂

i only have a question what do you mean with 'precise' ? 'sample-precise' ?

i mean

if i'd do a sequencer in SM (not a step-sequencer, a 'plain' one for wich we'll need midi arrays/buffers) with a resolution of say 240 ticks per quarter... what i'd need is precision at the tick level... if the BPM is say 200 the duration of tick will be

(60/200) / 240 = 0.00125 = 1.25 ms

( with a BPM circa =1000 !!! you'd go at more or less tick rate=SR 😀)

240 tick per seconds is the 'standard' resolution for midi sequencer i've seen around (some go to 480 ticks)

so i think this is the 'precision' needed for midi sequencing...

i don't really know what means 'sample-precise' sequencer (like logic or cubase or others)...maybe they refer only to VST instrument sequencing? i don't really know 🙂

lalo

jorge · 18 May 2005

We'll definitely need sample precise Midi support inside SM but it's only useful once we have proper sequencers etc. At the moment you want notes to play as soon as possible, there's no need to deal with sample precision for Midi.

But for a basic sequencer the not sample precise windows events would be useful for now. And they're definitely enough for animation and GUI refreshes etc.

For a proper sample precise sequencer Midi events would be defined in terms of samples, not ms.

lalo · 18 May 2005

jorge wrote: We'll definitely need sample precise Midi support inside SM but it's only useful once we have proper sequencers etc. At the moment you want notes to play as soon as possible, there's no need to deal with sample precision for Midi.

But for a basic sequencer the not sample precise windows events would be useful for now. And they're definitely enough for animation and GUI refreshes etc.

For a proper sample precise sequencer Midi events would be defined in terms of samples, not ms.

well said 🙂

unkargherth · 18 May 2005

Well, this starts to sound as the eternal discussion between Synchronous /Asynchronous events....

I think milisecon precision isn't enough. Sample precission would be perfect, but easily could hang up machines

IMHO,a third solution is to Have an accurate n-samples precision, I mean: I found really a small number of situations where it's critical you something on current sample and is a disaster to do it in the next or in the previous. But what is posibly more offten Needed. is an absolute thruth on "On which sample is this happening"

I mean. Most of things could be done on a for example 20-samples precission timer, as long as you could put you hand on the bible and say. "I know that with independence of the situationi I receive a tick on sample 0, sample 20, sample 40" all the maths should be redone, but i think it should be posible.

Obviously , i'm not an expert and this is only my opinion