DSP Robotics Support

Hi guys

I thought I'd upload this to get your opinion on what I think is such a strange behaviour. Or have I been foolish somehow? Please tell me!

The fixed and later version is in the topic below and I had to make big changes to the schematic to get around the issue:

viewtopic.php?f=3&t=3611

When you run the QX7 try changing the preset from 1 to 2, from Bella to Joanne. Note the instability of the fixed frequency displays on OPs 4,5 and 6. This erratic readout can be stopped by switching off (bypassing) the Reverb module. In some cases the Chorus module can also cause the problem. After several seconds the displays settle to zero but will start dancing again if you play a note. Or, with it on zero, try adjusting the coarse or fine knobs on the affected OPs.
I've tried loads of variations of the OPs schematic, just for the fixed Frequency control, but still got the same result.
Interestingly, if you disconnect the 2 feeds from the OP stacks from the Combiner below and then re-connect the fault will move to whichever stack you connect secondly. So you can make the fault move to OP 1,2 and 3.
I've recopied OPs, deleted and re-inserted the Reverb (from earlier working Quilcoms). I've tried using stream components with Poly readouts instead of mono and using a Combiner on the selectors' outputs and a mono display - this worked but I got horrid clicks with every note played. I've copied and pasted the whole schematic into a new empty one.
I have found that the actual frequency produced by the affected OPs is perfect but the display isn't. You can see the erratic signal on a scope but it doesn't affect the frequency, which leads me to think it's a strange display-related issue.
If you disconnect the fixed frequency line from the Selector Prim the scope then shows a steady level from the knobs' circuit. SO, I made a selector using DSP and, believe it or not, I got the same result so it's not really a selector issue I'd say.

I've spent 1.5 Flowstone days on this and in the end I moved the knobs out of the Operator modules and connected the circuits wirelessly and it works perfectly.

I would really really like to know if I've transgressed a Flowstone rule and what the rule is, so I can avoid this type of configuration in the future. At the moment I feel FS is not doing what I ask and expect but, hey, we are learning all the time so maybe it's me.

I do hope to hear back from you experts. Please?

Cheers

Spogg

The solution I mentioned above did work but I've made another one which someone might find useful.

This is dead simple and it worked in the module above and was nice and stable, as I expected the original one to be!

This solution avoids any cross-pollination between mono and green which is where I expect the problem lies, even though the details of the cause evade me. I don't see, for instance, why some Operator modules work and some exhibit the fault in the original.

Whatever!

I've had no replies so I have to assume that nobody else has resolved the underlying issue (yet?).

Cheers

Spogg

I have no real explanation, but it looks like there is somewhere a memory overlap. Maybe there is a write to an input in some Asm/DSP module that causes it. Maybe the schematic uses to much memory and it is getting wrapped around... not sure hard to track down. Only thing I figured out is, the value is not jumping but very slowly sliding like in a low pass when you pass a step impulse to it.

You'll have to remove as much as possible (but still keeping the bug)... and then you might figure out the cause.

Hey MyCo thanks for looking at this for me.

The easy way to stop the behaviour is to bypass the Reverb module on its front panel to stop it using CPU. Or reduce the number of Operator modules, that works too. However the CPU use is not so high, so I can't think it's a resource issue.

If you scope the erronoeus signal you'll see that after releasing a note on the USB keyboard the amplitude of the jumpy waveform decays over a few seconds, like it was being passed through an envelope system with slow decay settings. None of the envelope setting in the project affects this decay though. I would have thought that if it was a resource issue this wouldn't lead to this weird decay effect. Maybe it's a bit of black magic in the Reverb module (taken from the Analogue Kit which I think you may have made) but I've used the exact same module in all my Quilcoms and no problems happened.

The really weird thing is that it doesn't manifest any audible effect on the fixed frequency itself; it ought to be very unstable given the value excursions visible on the Readouts and the scope. This suggests to me that the unstable signal is not really coming from that point in the schematic but is more likely to be received "telepathically", i.e from some oddness in the compiled code.

What is important for me is to know that my schematic is "legal" and I haven't made something wrong in terms of the rules for Flowstone schematics. I have solutions but these were resorted to as a result of something wrong which I didn't expect to be wrong. So you could say they were a work-around. I need to know why the original doesn't do what I believed it should.

I shall wait a while longer in case somone here comes up with an explanation and if not I'll pass this one on to support.

Cheers

Spogg