DSP Robotics Support

MyCo wrote:

tester wrote:If in the schematic a lot of triggers are wandering in "paralel" threads

No, all triggers run in the same Thread! They are serialized. So there are never 2 or more triggers at the same time!

tester wrote:is there a hidden rule that decides which triggers have greater priority than the others?

The rule isn't hidden, it's called trigger order. That are those gray markers, that you can see on connections.

Let me specify my first question/concern. I mean a situation in which triggers originate from certain/one source, but then they follow parts of schematic that are independent from each other ("tree" so to speak). So I'm not sure how the trigger order is related to this aspect, because each "branch" of that tree has it's own events (like need for user interaction to generate something new, or timers that break john into mark and sam instead of john1 and john2), events that break the original order of total flow of triggers. Yes, I understand (I follow you), that triggers are re-serialized then again, but even if so - my question goes back to priorities of how the whole thing is put together then, or - what kind of influence schematic can have on that. Do you have any experience with it?

Anyway by paralel threads I mean paralel/independent on schematic, not in regards to CPU. Sorry for confusion.

First trigger is served first. As I said, everything runs in the same thread. So even triggers are output one after another no matter how you structured your schematic. They are generated in series and received in series

...but have different nano/micro-delays reaching destinations (important only in certain cases?), yes? The reason I ask is, because in ongoing flow, there is no such thing as a "first" trigger, there are only "holes" between triggers, other triggers are placed, if this whole thing is serialized. It isn't happening in "timeless", but I'd like to know if the time frames are "noticable" or not. Or what do I miss?

I don't know what you mean. Timeless? Holes? No, triggers are placed one after another. And if one trigger triggers another trigger, those triggers are executed before the other triggers.

Excuse me for interrupting Myco & Tester, but

billv wrote:2 defintions from me are......
a. That "ugly" screenshot I keep posting that you hate so much(so I won't post it)...."screenshot 214"
b. The Loop creation method that yields a sample that is "sample accurate" as discribed in
the link I posted earlier in thread , the one relating to audio.
You will also need to explain, how these two defintions are false.

This needs to be adressed.
Or
I can even provide you with a way out of this mess.

Myco, Please tell me how to obtain an accurate reading in a host.
And, I'll happily start testing again from scratch.
Just to suit your stubborn ego.

MyCo wrote:You've done "practical tests"? Really?

As we can see, there's nothing in the timing thread is there...
Pick any one in there Myco, and generate a error of more than 1 sample.post your evidence.
(note:if you choose Drum machine...change sample in slot 1...its a dodgy sample)
i suggest you try the "Myco timer"...... ...I just love the irony....
And bear this in mind mate, Trog has done a lot of work in this area, yes??
So way back near the start of the timing thread, where i jump for joy and say
" hey man, i got it in green"......then later down the line Trog replies something like
"Great, it's good to see the green part is not throwing it", think about this....
Myco, given the time trog has spent on this, do you think he just took my word for it?
Na mate, I'll bet my balls that he loaded the damn thing up, recorded the output, then
stretched the resolution all the way to the very last sample refernce to see exactly
what the result was. As an experienced musician he also knows the "ballpark amount"
of error required that gets you a bad result, after you cut a section of the recording out,
copy/pasting to form a new loop that rings "true" in a real world scenario.

I think when Trog catches up with you he'll cut you up into little pieces and put
put you in his Figroll and eat you for breakfast.
Try a fsm....post your evidence.

MyCo wrote:When I output an event at a given time into an audio stream (which get back into the host) then it should get in the hosts audio buffer at the same position where all other hosts events for that given time are. Or simplified: When I output a sample at a time 123 which corresponds to the sample position 234 of the current buffer, then the host recieves that at exactly this position.

Interesting.
Try a fsm....post your evidence using your method of examination.

In other words....

Record the output......

Then cut a section a section out....

Then take that piece of audio, copy and paste it several times to form a new loop...

I'm getting a "sample accurate loop".
Therefore we are back to the statement...
"S/R Accuracy in Green is possible, but NOT RECOMMENDED"

Theory
try with poly note

Surrender Myco,
Drop your weapons.
Your stuck in a ''supergreen" ambush....
Surrounded by ruby...bound... with no way out........

Tronic wrote:Theory
try with poly note

I think that method is covered in the Drum Machine upload.......tested fine.
Please correct me if i got your question wrong...

I can't believe that I'm still wasting my time with this stupid bullshit. I haven't found a "green timing" in the timing thread, so I thought I just break something just for fun. So I took your "X11 2.01_v3_Timer.fsm" and exported it as VSTi. Since there is no PPQ the breaking task wasn't that hard. I've just set an unquantisized Loop end, and after the first runtrough it was completely out of sync.

Here is the FLP with the looppoints and the VSTi DLL

This'll happen with "Ruby test_0_with PPQ_Myco style.fsm" and "Ruby test_0_with fL CLOCK_4.fsm" and some others, too