Newbie question. Mixing Poly and Mono in schematics?

[martinvicanek]

No need to share the entire schematic. Strip it down as much as possible, so that the problem (which you want to solve in the first place) still shows. That way it will be much easier for others to help.

[R&R]

Problem seems to have been the two utilized CPU-cores in my laptop hitting 100%
Switched to a faster laptop and the real world CPU usage measure only 33% now. Everything seems to work flawlessly (well we'll see )

Unfortunately I ran into a little hickup of Flowstone itself. Have to switch to yet another computer to continue working.
Alot of thing to optimize... once I know how. But that can wait as long as CPU can handle the project.

I guess FS prioritizes execution in the order of skipping outputting green, then blue and finally poly... resulting in crashes...

[R&R]

So I've been testing, testing, testing... and testing
Poly always works. Blue though...

The most reliable or should I say "the always working" blue schematics inside FS, is when I have an always connected blue ghost LFO-oscillator (preferably one of MV's ASM's) in parallel with my "actual" switchable free-running blue LFO's.
This ghost oscillator is multiplied down to 0 output meaning it's always running silently, without any multiplexers/selectors in it's signal path. I've tried a DSP snippets that just outputs whats going in. Didn't work, but might if it does a multiplication or something inside. Maybe.

Nevertheless, when I export to an EXE I get a varying results... EXE-exports doesn't seem to work the same as FS itself. It performs much worse against ASIO. In my mind it should be the opposite

Most commonly funny enough, the primary soundcard-output (non ASIO) is the one that usually works with the free-running LFO's in .EXE exports. ASIO however Selecting ASIO crashes the .EXE quite often, but usually the free-running LFO's don't work or when they do stops working right away.
I've put a button for a clear audio-prim in the GUI. Sometimes the free-running gets going for a short while after clearing all streams. So... A latency and audio-buffer issue it is then...

I have a humble question about this, without knowing anything about the heavy coding aspects/development...

If the blue streams are actually realtime (system-, audio drivers-latency and- ASIO- buffer-dependent)... couldn't FS in theory be updated to allow an introduction of internal delay to garuantee full execution of it's own audiostream components?
As it is now... Having schematic functionality-dropout is much much much worse than allowing for configurable latency tolerance or even silence (when system isn't up to the task) in my mind... Even crashing is better than non functional features inside a plugin (from a UX/usability perspective).

It would be nice to know how FS handles Mono contrary to Poly. Since Poly always seem to work

[Spogg]

First question…

What version of FS are you using?

[R&R]

I'm "still" on a demo of FS version 3.0.8.1

Will move to get a copy of FS as soon as I feel confident the essentials of my synth will actually run

Btw
I've encountered some bugs in FS (sorry... I mean "features" of )
Funny enough I have some experience within testautomation lol

Where is the best place to post bugs?

* File save issue (already reported to Malc (forum admin?) and issue should be fixed in next release)

* When copying/pasting modules the schematic isn't always updated/reloaded causing ghost interaction of pasted modules/prims to the old connections

* Having a curve spline connection to the upmost left (near y = 0) on the FS grid/workspace and then selecting and moving a bunch of modules (including the one with the upmost left spline) will shoot them "all the way to the right" (right end of the grid). Even beyond the grid! Causing mayhem trying to return them to the grid (Tron reference? )

* Terrible behaviour with Reapers x86 bridge, but probably a Reaper bridge problem... Have to close the plugins UI and then reopen to get the right behaviour otherwise there is somekind of funky click-event "window out of focus" issue affecting the dropdown menus (which are likely windows functions/framework for dialogs?)

[R&R]

I should also mention that I test using two setups... One using ASIO4ALL and one using actual ASIO drivers on two different Focusrite interfaces...

[R&R]

* Having a curve spline connection to the upmost left (near y = 0) on the FS grid/workspace...

Correction I meant near x = 0 of course. But near y = 0 (upmost top) has same issue. Seems like the spline control points (or something) are taken into accout when calculating the selections boundry causing selection to shoot of if there are spline-connections that have large curvatures.

[Spogg]

Demo of 3.08.1: I thought you only got a week with the demo version. Has this changed or have you got a pirated copy? Or are you violating the license agreement in some way?
I’m not the Police but this might have a bearing.

We recommend 3.06 for better stability and performance.
Bug reports for 3.08.1 are no longer handled because FS4 is currently very advanced in development and that’s based on 3.08.1 code, so I’m told.

The schematic content should always be fully within the bounds of the workspace, as you found out!

Reaper: I use Reaper and test my 32 bit plugins in 64 bit Reaper and never had what you describe. I also test in Cakewalk by Bandlab and also never saw the problem. One thing that might help is if you select “Save minimum undo states” in Reaper for the plugin. Also, FS plugins need the Visual C++ 2013 redistributable package available free from Microsoft:

https://www.microsoft.com/en-us/downloa ... x?id=40784

You might not have the correct version on your PC and installing this shouldn’t cause any issues.

[R&R]

Demo of 3.08.1: I thought you only got a week with the demo version. Has this changed or have you got a pirated copy? Or are you violating the license agreement in some way?
I’m not the Police but this might have a bearing.

Pirated copy lol...
I'm sporting demo with 5 min limit on .EXE and noise VST plugin and ALL No problem running a demo on new machine image every 7th day. If that is against the license agreement well, then I have to quit all together then.

I'm not publishing anything and working within demo-limitations.
Can't even get the plugin to work as expected. "That" IS the problem.

[R&R]

The nature of this kind of software is that it demands investing countless hours of prototyping without knowing if the software is even capable of achieving the goal.

I honestly think that the demo-version period should be changed. But don't ask me what would be the best option, I have no idea...