vst exported not working + timing issues

[tester]

I posted earlier version of this problem on SM forum:
http://synthmaker.co.uk/forum/viewtopic ... 12&t=11949

But after doing some work in FS - I'm just too tired to rework it for SM again.

But another issue emerged, and I wonder if they probably would have the same solution.

So:
1) the "ping" works in exe app, and it plays live in vst plugin. But when rendering output file (wavelab) - it produces no sound. My guess is, that this has to do with green timing system, but I'm not sure on that. This is the major issue I have, and don't know what to do with it.

2) There is a timing accuracy problem related to triggers. If for each "ping" another frequency is selected, then from time to time (in greater design - much more often) - the "ping" is not synced with frequency change. I guess it does not have to be "sample accurate" (fade-in slope is 3ms long by default), but it would be nice to get smoother/synced changes all the time.

Help

//edit:

oh, and by the way - where is cyto?

[trogluddite]

Maybe this will fix the sync problem...

randping-syncing-possible-fix.fsm

(21.57 KiB) Downloaded 1118 times

... hard to tell for sure at the moment, as my little netbook always crackles when i use ASIO anyway!

I think the problem is with using the two timers. They are both just low priority windows timers, as so very innaccurate - in effect the two timers are running on independent clocks that don't keep time very well.
In the changed version - the envelope is no longer triggered by the second timer, but looks for the changes in frequency value directly in the blue streams, so that all of the stream modules are triggered on the same sample.
Not sure if that will have affected any of the other functions though, so I left the old components in too, so that you can give it a thorough test.

The Wavelabl problem I would guess is the same thing - the Timers always run in Windows time, without any kind of sync to the sample clock or host - this will affect any host if you try to render faster than real time. The only way around that would be for the interval timer to be code/assembly driven from the PPQ or Sample position primitives, so that the host's timebase gets referenced.
You also have a few presets there which have the 'record automation' enabled - this will often confuse hosts unless the preset values are kept between 0 and 1, as that is the range expected by the VST spec.

[tester]

Thanks, check on this one tomorrow, but I'm glad that someone did pay attention to this one

Don't worry about automation (but thanks for reminding in this particular context), it will be reworked separately, after I finish the core. I'm still re-thinking on rescaling vs minmax ranges in order to get the satisfactory accurate results (and without over-building the app).

From what I see, hosts seem to have two modes, one with automation and one without. For example, Reaper blocks the knobs on plugin's interface in the automation mode, and knob can be changed only via automation track, but not manually on plugin interface. The second point is what we discussed long time ago. With direct export - plugins can have their own settings (tested on multiple hosts), beyond (0-1) ranges; ranges matter in automation which is restricted to that (0-1) part; but I'm not sure if I did not see "scaling" in Reaper too.

[tester]

Brilliant idea with timing, seems to work fine.

Hmm... Right now, when exporting/rendering audio output - I get something, but not what expected.
I get one "ping" at the beginning, and then - only silence. Where did the other pings go?

It looks, that both timers are ignored anyway, because the first ping is with no initial delay. So the timers are not used in relation to samples. I thought, that timers, when rendering output - are recalculated according to samplerate somehow (so the trigger would be included after certain size of samples). Is this:

"interval timer to be code/assembly driven from the PPQ or Sample position primitives"

...what you talk about? I thought about slow ramp/saw based timer, but not sure if this will work as I suspect. I would need some trigger sent from blue (something like "if stream = 1 then send streambool value" or some in-code stream-to-01 manager?).

[tester]

If I understand correctly, the envelope is activated by any change on the blue.

So here is a concept of a blue timer.
1. Code input contains two values, freq1 (initial delay) and freq2 (regular cycle)
2. When turned on - code generates a ramp
3. First ramp cycle uses freq1 input value.
4. When ramp = 1, then input frequency is changed to freq2
5. Each next cycle uses then freq2 as a frequency

6. On the output... Each time, when ramp = 1 (or "max value"), output just switches between 0 and 1 (because envelope reacts to "any change").

Now - my question is - how to do it in "code"?
I have a hunch that this is easy to do, but have no idea how to make it.

//edit:
Okay, I was able to do the second part (the 0-1 did not worked, so split into 0.5 and extended time twice), but I still don't know how to make the first one - initial delay (first cycle with different lenght). Plus - I don't know if this approach will wpork with making the initial delay simple.

[tester]

Hm... I think basically I made it. The only things I need is to - reset/resync ramp when delay=1 (conditional resync).

But the good news is that it has pre-delay

Is there a way to simplify it? I.e. Right now it's as if there were two oscillators running inside, but it would be faster if only one was intact, just changing the input freq from one to another. Maybe hop 128+

[tester]

It looks... I made it!

Okay, next step - random number generator in blue, to sync it from blue/stream accurate code, without green timers or ticks.

[tester]

Found a problem. When "sync" node in timer code is connected - then:

a) in live playback everything works fine (it resets envelope correctly)
b) when doing audio export however - audio output is zero.

I guess that (again) this boolean converter (based on green timer) for resyncing makes this problem.

How to fix it?
Or how to implement different type of resync?

[tester]

I came up with something like this.
Not perfect, but at least - works on exporting and in live playback.

[trogluddite]

Wow - great little series of posts there - 'real time development' showing each 'bug' fixed one at a time, seems you are better at this than you give yourself credit for sometimes!

Haven't had a lot of time to look through the schematics, but I don't see anything that seems obviously 'wrong' or inefficient. Using a 'double length' square to generate 'edges' at the correct rate is a perfectly sensible solution, I have done that myself a few times in schematics that need 'syncing' properties.

Looking back at the earlier schematic, one thing that may be causing you problems is in the VST presets/automation. I see that some of the preset parameters have the input value connected directly to the 'record' input - which is likely to confuse the host....
Connected like that, any non-zero value coming in will be seen as 'true' by the automation recorder, and will lock the automation system in record mode until/unless the value happens to change to zero.
The record input is usually taken from the user interaction in some way, so that recording only happens when the user is altering values from the front panel, and then immediately goes 'false' once the user has stopped fiddling.
That's a bit trickier to do with 'one shot' changes like edit boxes - it requires a little trigger logic to make it work properly....
1 - you'll need a toggle of some kind (e.g. using a counter) - output connected to the 'record' pin.
2 - incoming value - 1st trigger route - set the toggle to true, entering 'record' mode.
3 - incoming value - 2nd trigger route - send the value to the 'value' input (record came on at (2), so it will get logged by the host).
4 - incoming value - 3rd trigger route - turn the toggle back off, to go back into 'playback' mode.

Have to dash now, but if you need to see an example of that, let me know and I'll try and post one later. (oddly, the SM stock boolean buttons, switches etc. used to show a good example of this, but none of the new FS ones appear to have the 'record' feature used at all - seems like a bit of a wasted opportunity!).