FlowStone 3.0.9 Beta2

[iman]

It happens when you eg. Play quickly in that order with long release

Confirmed. The same here. I hope you find a solution for it, because it is a basic feature and can affect the playability of every plugin that is made with FS.

[Spogg]

It happens when you eg. Play quickly in that order with long release

Confirmed. The same here. I hope you find a solution for it, because it is a basic feature and can affect the playability of every plugin that is made with FS.

This MIDI stuck notes issue is by far the most important fix for me, and I rate it above all the new features! I need to emphasise this and if fixed fully and finally I will buy the upgrade licence for the new version.

Cheers

Spogg

[MyCo]

The new sustain pedal problem is already fixed. But it might not be the last issue with sustain, because it's rarely used and therefor not so much tested in real use cases. If there is nothing else to fix I'll take a look at the mouseRUpCaptured thing

[Spogg]

The new sustain pedal problem is already fixed. But it might not be the last issue with sustain, because it's rarely used and therefor not so much tested in real use cases. If there is nothing else to fix I'll take a look at the mouseRUpCaptured thing

Thanks MyCo.

The use of sustain depends very much on the nature of the instrument sound, and also the playing style. Nobody will use sustain for a lead synth but many will for a piano for example. For this type of instrument the sustain pedal can make a huge difference to the sound, expression and performance values. In this way it's important that it works and works properly, even if the user base that would play like this is small.

I will buy the release version and give some feedback in due course...

Cheers

Spogg

[iman]

If there is nothing else to fix I'll take a look at the mouseRUpCaptured thing

There is an issue with mouse "Drag y" primitive. When the cursor input is set to "1", it hides the cursor properly but after drag the cursor jumps to a wrong position x=0 y=0. Other modes seems to work fine (0=Show and 2=Hide only)

capture.png (53.59 KiB) Viewed 43735 times

[MyCo]

That was reported before, it's already fixed

[iman]

Thanks Myco.. I did not see any details or list about the fixed items, I thought it was forgotten.

Anyway should we expect a beta3 version or the next release is final ?

[Rocko]

Rocko wrote:
2. Delay module (simple delay stock module) does not work on 3.0.9.2 but works ok on SkyLark.
Is this reproducible or am I doing something wrong?

MyCo Replied:
There were some changes to the delay code... so that could be possible. But which delay module do you mean? Can you post a test schematic!

I tried to reproduce it on another PC and I couldn't. could it to be an issue with specific hardware ??

In any case, see the attached schematic as an example.

[Spogg]

@ MyCo

Hi MyCo

I sent an email to support but didn't get a response, so I wondered if you could have a look at this please?

I’ve found an issue with Ruby-based controls. I hesitate to call it a bug because there may be no way around it.

This concerns VST exports of effects, tested in Reaper and Sonar 8.

When the DAW is inactive, i.e. not playing or recording, the output command in Ruby becomes inactive but the rest of the Ruby module continues to function.

What this means is that when I make a VST and see it in the DAW FX plugin window, some of the controls fail to operate unless I play the track or arm recording. These are the controls that use Ruby where Ruby provides an output for further use, such as a knob value or selection item. To me, as a user, this looks like a partially non-responsive plugin, since some stuff responds to the mouse and some doesn’t.

With help from the forum we’ve determined that it’s the Ruby output command. Any drawing and mouse actions inside Ruby are still active, even without playback or armed recording.

In Reaper there is a setting to run FX without play running and this solves the problem, but the default for this is off. Reaper says it’s needed for certain VSTis. This means any user of my VSTs will need to change a setting in the DAW and I don’t like this idea.

I also tested with several commercial and free VST FX plugins and not one showed this behaviour, presumably because they don’t use Ruby as a development tool.

Here is a schematic and its VST export which demonstrates this issue.
https://www.dropbox.com/s/c28ovqr636qks ... g.zip?dl=0
All works well in the Flowstone edit environment but try it in Reaper or Sonar and you’ll see that some things work and others don’t or only partially work (unless you arm for recording or have track playback running). Interesting is that the Preset Manager, where the non-Ruby preset selection works but the rest doesn’t, due to depending on a Ruby module inside.

I can understand that the output command has no need to function if the output is for audio frames, but Ruby can output various signal types for many different uses and is more usually used for these.

If the output function depends on a clock signal or similar being present, could you generate a pseudo-clock if the DAW is inactive then switch to the real clock when the DAW plays or records?

Whatever the cause I really would like this to be addressed if at all possible. It would be nice to have consistency you see: Green always runs but with Ruby “it depends” is not really a good situation!

Cheers

Spogg

[tulamide]

I second what Spogg asked for.

Plus, I almost forgot about this: MyCo, if you find the time, please have a look at exported executables. You will see that there always is some kind of additional frame to the already existing window frame. It makes the executables appear unprofessional. Would it be possible to get rid of that additional frame?

Here's an image example: http://prntscr.com/batdwd
You can see that inside the window frame there are black lines left and top, and white lines right and bottom. In this example the blue rectangle is supposed to end at exactly the window frame right and bottom (just as the grey area should end at the window frame to the right, and the grey area topleft is supposed to start directly at the window frame.