DSP Robotics Support

big crash on my system

Tronic wrote:big crash on my system

Thanks for the report. But mate, will need more info to help sort your issue.
What is your System? Please define in some way...
I presume your using v3.
Are you in FS or Host?
If host...what host?
Are you using v3 as is, or is it changed?
If changed, can you upload fsm?
Can you repeat the crash or is it a one off ?

I can't produce a "wobble" let alone a big crash, on two systems and 3 hosts.
Very interested to hear your details.......

Did some tests using Trogs Ruby Counter in the v3 timer, for comparison against the green.
It really handles the faster speeds better than the stock green counter, so if your chasing
some sort of monster tick rate....tests show your better off using that.
..viewtopic.php?f=2&t=1378&p=5642#p5642

The circuit should be re-created in ruby, with a ruby count as well.
That will allow us to get those monster tick rates discussed earlier, enabling a more "pro" solution.

+1 for this man

billv wrote:

Tronic wrote:big crash on my system

Thanks for the report. But mate, will need more info to help sort your issue.
What is your System? Please define in some way...
I presume your using v3.
Are you in FS or Host?
If host...what host?
Are you using v3 as is, or is it changed?
If changed, can you upload fsm?
Can you repeat the crash or is it a one off ?

I can't produce a "wobble" let alone a big crash, on two systems and 3 hosts.
Very interested to hear your details.......

I think this info will be useful,
but I do not think inquiries concerning this because, all other vst I use, host or other software, do not crash.
FS in a random or unexpected he does, without much chance to go back to the reason, and in many cases without the possibility of replicating it.

I'm sorry but I think that what I said does not help much.

billv wrote:Did some tests using Trogs Ruby Counter in the v3 timer, for comparison against the green.
It really handles the faster speeds better than the stock green counter, so if your chasing
some sort of monster tick rate....tests show your better off using that.
..viewtopic.php?f=2&t=1378&p=5642#p5642

Where is that Trog's monster where?

Tronic wrote:I'm sorry but I think that what I said does not help much

Thanks mate...all good.

tester wrote:Where is that Trog's monster where?

Use link to find Trog's Ruby counter....capable of monster tick rates...

The rate can be maintained only by using ruby to ruby,
if trig is transferred to the greens they return in the thead of the greens,
then queued to other primary processes: audio, midi and ruby.

then as mentioned above, a high ratio of trig from ruby to the green
is only a mere overload of requests to the thread of the greens.
I do not think that this would bring benefits.

a RubyEdit, must receive a trig to run the code,
an event in ruby ​​world, so if you resend an event at any of its input, thus creating a loop,
you can get a high ratio of events, which will always be synchronized with the events audio, if activated,
then an event is generated every time you fill the audio buffer, the size buffer of your audio driver (asio or other),
the same events are generated from the primitive Frame Sync.

I'm sure there better ways to do it all.
I'll leave it for some Ruby guru to create the real thing that everybodys happy with.
Chalice still there on the table. Didn't pour any whisky in it.

@Myco..
That's great if DSPR can test the "supergreen theory" with your Ultimate proof FSM.
Closure on this issue would be nice, either way.
Bit Dissappointing if the community can't record a track and make a desicion with all the
"sample accurate " tools provided by the Host.
There seems to be a fear or lack of respect for Hosts in the atmosphere. Weird...