DSP Robotics Support

I'm afraid I don't follow re: 'setting connectors to data types'. ? What is it I should change?

From inside a module, right click on the circle part of an input/output connector where the links join on - it will show a context menu from which you can pick a connector type. Once you've done that, FS won't be able to change the connector type using the auto-detection system. The same works for wireless connectors, and allows there to be wireless connectors with the same name, but matched by their data type. It's also handy if you want to insist that an input or output has a particular type, but you're happy for other types to be converted (e.g. connecting integers to a float input).

OK understood - so where in my schematic are there unmatched data types?

You mentioned Ruby errors - are those in the maths inside Martin's Complex LP? Can they be corrected? I know they caused a problem before and Spogg seemed to find that connecting an AfterLoad prim to the input of that maths module helped (I forgot to add that to this schem).

That's the tricky bit!

I found the ones that I did by starting from the modulation matrix, as that's the part I'd experienced problems with, and also the part most likely to get broken (because of the need for matching types at each end of the bus). That found a bunch in the LFOs and the filter envelope, which setting the type just for those module's outputs seemed to fix - but I can't guarantee that's all of them, as it may depend what modulation routing was set up at the time. I would definitely set the type for all of the mod matrix module inputs/outputs, as these determine what types the mod-bus will use.

I'd also pay special attention to wireless links as, like the busses, these are easily upset by mismatches. The trouble is that you can't tell by looking whether a connector has a fixed type or has been set automatically by FS. However, you can usually check for sure by temporarily disconnecting a module's outputs (the type always flows "backwards" from output to input when it's set automatically). It's also worth saving and reloading often, so that FS is forced to "rebuild" the automatic types from scratch.

It is rather a chore, I'm afraid - good luck!

Yeah, FS can still be unpredictable in terms of connections and types- a lot of time's been spent diving through schematics just to find the culprit that needs the old "disconnect/reconnect" treatment.

The propagation direction also explains why a "module out" won't clear its type upon disconnection, but "module in"s will.

k brown wrote:Spogg seemed to find that connecting an AfterLoad prim to the input of that maths module helped

Yes, rather than rewriting the Ruby code, an 'AfterLoad' should be a reliable workaround - it's always the same little 'Math' module inside the filters that blows up, so there's only a single 'q' input to do it for.

So - - -

1) 'Hard-wired' envelopes to the matrix.
2) 'Hard-wired' connection to keytrack module inside mod matrix (the only misbehavior I've experienced was when using this).
2) Manually reset all in and out wireless connector types inside mod matrix.
3) Manually reset all wireless connector types on outputs to mod matrix.
4) AfterLoad prim in filter.
5) Pre-installed ASIO out module in schematc (not connected because my computer doesn't have any ASIO devices).

Replaced schem in original post.

Fingers crossed.