DSP Robotics Support

I do not want to waste time discussing things that are asked most experienced minds than mine,
just look like any other ruby systems have been created to solve this problem,
and in addition this system ruby is embedded.

if the ruby was appropriate to ensure accurate sample systems,
there would be a massive development around it, and would be released enormity of software and solutions.

but here we discuss the Green , you know what we mean in slang developer?
When you have found an answer to the truth.

yeah billv, just keep on posting meaningless screenshots. That'll help to make your position clear!

have another nice day!

There are two approaches. Re/source oriented and result oriented. If for some reason biliv gets proper results with improper resources, then we have a mystery. How to apprroach the mystery then?

1) First - I would check the mystery in various conditions, without modifying the schematic. If the mystery repeats itself, then it must be something inside application that generates proper results.

2) Second - I would focus on the testing design itself. biliv provides screenshots, MyCo creates comparisons via partial schematics. None of these approaches seems to be right however (and not due to sample accuracy/inaccuracy). The reason is simple. Practical results usually accept some degree of error (some degree of variation, depending on where the driving signal bonds other signal guts; "humanization" protocol?). Theoretical results are sample accurate, but not always the best ones (phase coherence and peak amplification) for the ear.

3) Now, if you know how the mystery behaves in various conditions (objective fact), and how it behaves under contextual test design (objective fact) - then you can try to figure out what is going on on the programming level. Not before. Otherwise, both sides will take the subject in a tendentious way, i.e. nobody will do anything, and everyone will speak from their past experience, but not from the experience related to the mystery itself.

So my advice: biliv - you must create a "test design", so that someone else may see/hear the same results on first place. Give there a living schematic with an output selected by you (taken from final sound output which represents a total sum?). If achieved results will be in contradiction with healthy reason, then there will be reason to digg deeper. What do you think?

//edit:

Hint. A test design is made of:
a) schematic
b) reference signal (wave or stream?)
c) stream combiner (schematic + reference) after which you can do whatever green visual representation you wish to show (reference and produced signals are combined)
d) step-by-step procedure

Hope this helps.

Here's a random thought, Get a faster machine!!..

...we are doomed... :-/

Meh.. Mostly the need for uber timing will be combatted by sufficient timing.
Think understanding what type of hardware you use for what purpose will end this discussion.
That's why some experts will be not getting through some thick heads.

...we are doomed... :-/

Oh yes

it's unfortunate then ... this could have been an educational opportunity in this public forum.

At least I have some code examples that I can test [and try to learn from] on my machine.

Maybe a new thread will start on this topic.