We create a feature list for the next update fee?

[theun]

Hi, I'm back here!

Though I have checked this board almost on a daily basis I guess I haven't posted here for a long time.
I still like the graphical way of programming of SM a lot. However I slowly lost interest because there are too many real show stoppers. The two main show stoppers (for the kind of applications I want to make) are:

a) timing system (I'm working on sequencer-like stuff for algorithmic composition techniques)

b) vst sdk 2.4 or higher compliancy missing (so you cannot guarantee a vsti or vst will work in any daw/sequencer)

There are many other wishes or (minor) bugs, however in most cases more experienced users are able to invent workarounds where neccesary, however for the two problems listed above there are no workarounds.......

Further, to my opinion the status of the documentation is a shame, e.g. all components introduced after 1.0 are still missing in the component reference.

regards to all, theun

[mwvdlee]

Most importantly...
* The three bugs listed in my signature.
* As many other bugfixes as possible.
* Support for the most common host applications.
* Improved stability to a level where you can use it for live performance (from what I can tell, this has mostly to do with memory management issues; S|M doesn't seem to deal well with memory-to-disk swapping).
I can't stress enough how important it is to have a solid foundation before adding features.

As for features, I'm really looking forward to having the audio device selectors available in FlowStone. Since they already exist, I'm assuming they'll be in the next release so no point in putting it on my wishlist. Other than that...
* The ability to disable the zoom and use the scrollwheel for something else. (I'd rather have the zoom functionality removed completely from the editor as well, but that's unlikely to happen.)
* Ability to disable the menu in compiled .EXE's completely. Perhaps Flowstone can already do this?
* More ASM commands; this should be trivial to implement and allow the developers to create many of the items on other people's wishlists.
* Shared memory for the poly's; basically like the blue memory write, but for polies.
* Better multicore support. S|M only seems to use one core, even though it has atleast two threads. I don't like my sound getting choppy when it's only using 50% of total CPU performance.

Obviously many more additional features would be welcome, but I'd be more than happy with just the first list.
I wouldn't pay for an upgrade if the first four points weren't addressed properly.
I'm pretty sure most people will gladly place those points prior to whatever wishlist they posted here, albeit with perhaps a different preference as to which bugs to fix first
It's rather pointless having cool features when the platform they depend upon isn't dependable.

In fact, forget all the previous stuff; here's what I'd pay for:
* Bugfixes
* Stability
* Compatibility
AFTER those are addressed, I'd gladly pay for features. But until then, new features are just a waste of time AFAIC.

[exonerate]

@mwvdlee regarding the issues in your signature..... In flowstone there is a component which lets you choose the delimiter for a string array, I tried it and you can use commas in the string no problem.

Also in flowstone the shell execute has a new input to "run in background, ie don't wait for completion" not sure if that is related to your issue?

Not sure about the other issue in your sig, but you could always load up flowstone and test it.

Cheers

Exo

[Andrew J]

- basic support for multitouch windows events (yes, I have a multitouch-able computer now). Should at least support more than one mouse drag at the same time and basic swipe gestures

Cue Pablo!

?how much does a sourcecode license of synthmaker cost?

Ooh-er!

[mwvdlee]

@mwvdlee regarding the issues in your signature..... In flowstone there is a component which lets you choose the delimiter for a string array, I tried it and you can use commas in the string no problem.

Also in flowstone the shell execute has a new input to "run in background, ie don't wait for completion" not sure if that is related to your issue?

Not sure about the other issue in your sig, but you could always load up flowstone and test it.

Yup, those two fixes seem to be just right. Haven't tested the shell exec, but I have faith in that it works.
That just leaves the enveloppe control and obviously stability and compatibility for me.
Starting to look good

[trogluddite]

Something inspired by the ongoing 'better green timing debate...

Green is good for infrequent, unpredictable events (i.e. user interaction); no triggers=no CPU load, great!
However, the CPU overhead of tracking triggers makes it unsuited to 'medium speed' predictable regular events (i.e. sequencers etc.) - using hopping on streams is a much more efficient way to deal with that kind of event while lowering CPU load...

...but currently only code/asm geeks can hop... (must be the deep vein thrombosis you get from sitting stationary in front of a PC too long LOL)

...so how about a 'Hop Module' - a module container that hops any stream components that you place inside it!

Add that to an accurate Stream to MIDI primitive and maybe we can kill the lumpy sequencer timing debate once and for all.

Of course, we may also need stream equivalents of a few of the 'Green Only' primitives (counters etc.) to make life easier for newcomers - but as the 'Developers Toolkit' and 'Missing Links' collections show, there are enough SM power users here to construct most of that stuff without breaking a sweat.

[mwvdlee]

Add that to an accurate Stream to MIDI primitive and maybe we can kill the lumpy sequencer timing debate once and for all.

Perfect green timing would require a real-time operating system, which Windows (or OS-X or vanilla Linux for that matter) isn't. It might be improved, but would never be accurate (or reliable) enough.
As I stated before, I think most of the trouble with "green timing" comes from the inability to output accurate MIDI (if anybody else has a good reason for wanting perfect "green timing", then please explain), which would be better served with a Stream-to-MIDI component.

[tektoog]

I'd like to be abe to do web stuffs... SM is good for graphic I think...It coud be really used as a kind of Flash graphic tool to implement audio widgets or quickly design web menus, tabs, or just background graphics... I already used some graphics I made with SM in my website (frames and background)...
I' m kind of frustrated as I tried so many ways to incorporate my Psy-Radio Selector ...
viewtopic.php?f=12&t=9464&hilit=psyradio
... but with no success...
There is absolutely no ways (at least to my knowledge) to insert an .Exe in a web page (question of security breach...) So an export format like JS (Jquery) for web implementation would be also very welcome...

But it's just a thought....

[Disco_Steve]

I think that is more of another SM spin off, but I love the idea!!

[Tzarls]

I (if anybody else has a good reason for wanting perfect "green timing", then please explain)

FFT (and/or convolution) using the included green primitives comes to mind.

[ccpurno]

I think full Cubase support (= update vst spec) and better support for sequencers and midi arps should be top prio.
(and of course fixing bugs without workarounds)

But I'd like to suggest a fair voting system for choosing the focus points of this payed upgrade.
Check: http://uservoice.com/?referer_type=powe ... loc=bottom

CC

[Cyforce]

- better filters, also with slope-choice
- more effects
- better poly-to-midi modul with more option
- sample-container alà sf2/nki with much space for customizing

[adamszabo]

Id love to have the option of the preset manager also using .fxp and .fxb, as thats the vst standard.

Also, it would be great if we could have two schematic windows, like I zoom in the module deep, and in the other window I zoom out to my knob, and if I turn my know I can see that's happening deep inside. It would really help development.

[AndydeMaro]

- Adding new Compilersystem VST2.4/3.0.
- Mousewheel Support
- DSP_Framework
- More Commands ASM SSE4

[trogluddite]

-Proper handling of PC keyboard events.