Newbie question. Mixing Poly and Mono in schematics?

[R&R]

Malc (forum admin?) wrote they have issues with email confirmations etc. I had to email to activate my forum account in the first place so... seems a related issue.

Edit: In the meantime got the files from Malc. Didn't get links to 3.06 but maybe soon.

[R&R]

My synth has is a very basic structure like an "example synth". But on steroids.

Issues or not... I'm impressed that FS can handle the amount of stuff I'm throwing in there.

2 filters, 5 envelopes, 2 LFOs (not free-running right now due to the issues with blue), pitch mod, velo mod, panning, cross modulation between mod env and LFOs etc. Have had to add all sorts of compensations and adjustments via prims.

Right now it's cut in half but hopefully in can throw in everything. Might have to reduce voices even further though. I don't wan't the synth reaching over 20% actual cpu of an i7

[R&R]

What do ya know!... some progress time to take on a reductionist approach for a while.

The behaviour of FS prims isn't always what I expect is seems. I realized for example that buses don't work as I thought "under the hood". Unnecessarily exposing bus-streams to each other (probably adding them) and components/prims when not needed, eats cpu like nothing else

Gave up trying to modulate free running LFO's all together.
Works now. Barely... but my 3 main synth-knobs have started causing clicks in sound without any changes to that part of the schematics. Don't know why yet.

FS (3.08) crashes after a while sometimes, when playing notes. Seems without any apparent reason, Can't see any pattern of interaction or cpu-load causing the crashes. Comparing to other softwares i've tested it "feels" like a memory-leak or something lingering that should have been cleared.

Haven't gotten a chance to test with 3.06. Sticking to 3.08 for the moment. Using 3.09 beta only for 64-bit exports.

Was happy to see that my plugin works quite well atleast as .EXE in 64-bit from FS 3.09 beta. More than halving cpu-load. Pretty sweet!
But, seems that my snippet for syncing oscillators on incoming stream-changes don't work at all in 3.09 beta
Pretty critical simple function for the synth.

DSP snippet for syncing that doesn't work in 3.09 beta

sync.jpg (50.05 KiB) Viewed 8788 times

Anyone have an alternative DSP snippet that does the same but works in 3.09 beta by any chance?
Maybe it's done completely wrong.

[Spogg]

The issue is you’re supplying streamboolout as a numerical value rather than True or False. You can get away with that in green but not DSP. In the green world True is the same as 1, but not in DSP.

The line should read

Code: Select all

out = (control != prevcontrol);

This may not need brackets in this instance but whatever…
The expression will either give a Boolean True or False which can be used elsewhere in DSP when a proper True/False Boolean input is required.

[R&R]

The line should read

CODE: SELECT ALL
out = (control != prevcontrol);
This may not need brackets in this instance but whatever…
The expression will either give a Boolean True or False which can be used elsewhere in DSP when a proper True/False Boolean input is required.

Awesome thank you Spogg!
I'll try that out and see if it works in 3.09.
My old faulty one worked in 3.08, probably a fluke...

Hmmm...
Think I just got rid of the bad clicking and graphical glitches of my 3 main knobs.
Seems like (just as with buses) that exposing modules to those values, even though the modules should be disconnected at their output, is causing some "other worldly" ghost-interaction. A mystery why it started manifesting right now. Without any changes to those part of the schematic.

[R&R]

The statement..."an error type can have several causes" within the testing-field always become a little "meta" in softwares like FS

User error and bad schematic... or software bug, that is the question

[Spogg]

... User error and bad schematic... or software bug, that is the question

When your DSP code doesn’t work or does weird stuff, the normal sequence is
1) Blame FlowStone.
2) Restart FlowStone.
3) Find out what you did wrong.

One thing to be careful of is to only use letters and numbers in input, output and float names. You can have perfect code but it won’t work if you’ve used an underscore for example. And no spaces!

Something else I should mention, which you may have seen, is that if you have some duff DSP code it can affect other parts of the schematic not related to it. I suspect it messes up the whole compiler.

[R&R]

When your DSP code doesn’t work or does weird stuff, the normal sequence is
1) Blame FlowStone.
2) Restart FlowStone.
3) Find out what you did wrong.

Naturally... lol

It was a big gain in stability though when I started replacing my selectors with new ones as you suggested earlier.


This time it was a "3" (probably is most of the time) Not only was my dsp wrong... I forgot I had a second sync connected for when inverting waveform... again with my genius faulty snippet. Damnit! I get tired of myself

[R&R]

Have been struggling with another DSP... finally... finally succeeded

But not without wondering why things aren't working as expected again...

I was trying to run "trigger" from midi2poly module through a bus... Eventually after wasting alot of time on the DSP, thinking it was the problem... I hooked up a scope on the other end of the bus and noticed that the triggers weren't passing through the bus. Connected the "bus create" to the polystream directly (the "trigger count" from V to P prim) and changed all stream input/ouput types all the way to my destination module as needed... still... nothing!

Then finally... I ran "trigger count" from V to P prim up the module hierarchi to a wireless output to catch it where I needed it directly... and then! it worked!

Those buses again...
This time the bus in question shared module input with other buses but they don't share any polystreams or values...so nothing "should" have been added or anything. If that is even how they work?

Should I separate bus:es to separate inputs as well? I've started keeping them isolated from eachother as much as I can...
Feels like buses...as with regular code, should only be a way to access and set values. In this case It can be value-streams as well. Aren't buses only logical collections of data points for retrieval and setting values?

They seem to be a source of chaos

Am I missing something?
(yeah don't write "brain"... I know you all were thinking it )

[R&R]

Is this a case of "always create a new bus create/extract when changing them or their connections"... or?
A bit like the selector prims?