IYHO, what does SM need immediatly next?

infuzion · 9 Dec 2005

I personally am unsure what to vote on:

1) writing a doc on new primitive would help the devs see that primitive from the users' perspective (& make impovements before release), help find bugs themselves (Str->ASCII int bug should have been caught before release), & more docs will keep new SM users interested

2) I'm very concerned that my released VSTs will not be widely used because of high CPU & memory resources used

The other stuff is neat, but not TOP priority IMHO. But I assume to others they could be!

skOre · 9 Dec 2005

I chose the bugs, I also count bad cpu eating behaviour as a bug 😉

rl · 9 Dec 2005

I voted for "Code (primitive) additions" because bugs have to be fixed, documentation has to be written, CPU hast to be reduced anyway to make SM successful 😉

Shifrin · 9 Dec 2005

rl wrote: I voted for "Code (primitive) additions" because bugs have to be fixed, documentation has to be written, CPU hast to be reduced anyway to make SM successful 😉

I voted the same thing, code additions would rock and make my life a lot easier - and like you say bugs have to fixed, docs written, and CPU usage reduced 😉

Shif.

malc · 9 Dec 2005

Nice thread, rest assured that we'll be looking carefully at the results.

Just so you know, our current top priority is bugs. We also want to get the documentation moving soon.

[EDIT]Currently a bit worried about the attention that option 6 is getting but then again the Monster Raving Looney party always receives a few votes in the UK elections 😉[/EDIT]

rl · 9 Dec 2005

... must put out my sunglasses and fake mustache and vote a couple of times for my favourites.

Kara · 9 Dec 2005

I think smaller CPU & memory usage. A simple audio-switcher 1 channel IN , 2 channel out takes 2 MB as a VST !!!!

Rony

NothanUmber · 9 Dec 2005

I'd vote for physical modelling modules based on the m theory (that way one could perhaps build a big bang simulator and simply press the fast forward button until a great player with a fantastic instrument arises. Then all one would have to do is to say him what he should play and listen) 😀 No, fixing bugs sounds good as a start. (As well as a more universal code component, increased speed and that usb cable idea sounds really nice although I'd vote for a contact-free telepathic interface as usb is more uncomfortable if used for a longer period of time)

Greetings, NothanUmber

infuzion · 10 Dec 2005

rl wrote: I voted for "Code (primitive) additions" because bugs have to be fixed, documentation has to be written, CPU hast to be reduced anyway to make SM successful 😉

Yes, but of the bug-fixing, CPU issues, & docs do you think is most important right now?

Shifrin · 10 Dec 2005

Out of that shortlist it would have to be bugs!

Shif.

kessito · 12 Dec 2005

I would have to say latency report to host really.... 🙁 .. and of course the cpu drain could b lower

kessito

fritzman · 12 Dec 2005

Bugs. This makes it easier to find out without the documentation who's fault it is when things are not working. 😉

Best wishes, FRitz

Sk · 12 Dec 2005

Although the last one would be great (even though some older models of us don't have a USB port 😀 ), I vote for a better documentation and a comprehensive set of tutorials, especially with regards to graphics and non-sound programming.

infuzion · 13 Dec 2005

Sk wrote: Although the last one would be great (even though some older models of us don't have a USB port 😀 ), I vote for a better documentation and a comprehensive set of tutorials, especially with regards to graphics and non-sound programming.

You know, though I totally agree with you for the need, I think us users can write the docs, & the devs can spend more time... developing? Or do you think it's best for us to keep hands-off for the docs?

Shifrin · 13 Dec 2005

infuzion wrote: You know, though I totally agree with you for the need, I think us users can write the docs, & the devs can spend more time... developing? Or do you think it's best for us to keep hands-off for the docs?

To be honest I think the docs should be written by the devs, there should be a complete manual/reference available when V1 ships 🙂

I know that for example pretty much all the documentation for EnergyXT is written by the users, but you can't totally rely on people being there to write/update it. I've used XT since it's first beta release and it has taken a long time for the docs to appear, so I'm in favour for the devs doing this. No reason why us users can't maintain the wiki though 😉

Shif.

fritzman · 13 Dec 2005

Shifrin wrote: infuzion wrote: You know, though I totally agree with you for the need, I think us users can write the docs, & the devs can spend more time... developing? Or do you think it's best for us to keep hands-off for the docs?

To be honest I think the docs should be written by the devs, there should be a complete manual/reference available when V1 ships 🙂

I know that for example pretty much all the documentation for EnergyXT is written by the users, but you can't totally rely on people being there to write/update it. I've used XT since it's first beta release and it has taken a long time for the docs to appear, so I'm in favour for the devs doing this. No reason why us users can't maintain the wiki though 😉

Shif.

Absolutely agreed!

Sk · 13 Dec 2005

Maybe there should be some basic tutorials and reference written by the devs, who are the only ones to know whether a component must be placed in the upper half of the screen to work 😀 . But I see no reason why the users can't write advanced tutorials, or maybe some starter's guide.

I'll try to clear this as it may seem confusing. A user could well write a guide like "you, who are a complete newbie to SM, can make a VCA by multiplying your sound and the output of an ADSR component", because it's hard that a newbie can learn something wrong from such tutorials. But no tutorial written by a user should be taken as a reference when it comes to detailing certain components. For example, only a dev (or maybe a VERY experienced user) could write a tutorial describing how poly and mono works, because when the newbie (or the inexperienced, if you wish) is given some wrong vital knowledge, then he'll surely use it to mess everything up (Murphy, you showed us the truth!). Again, when this things are cleared by the devs, I would think it's ok if a user writes a tutorial about "how to create a custom slider" or such. Think of SM as of C language: no user teaches you how sprintf() works, but he can teach you how to use it to make a menu.

infuzion · 18 Dec 2005

I cast my vote! After the frequency in Hz change takes place, I'd like to see the CPU & memory usage whittled down near, if not past, the equivelant to what it would take SynthEdit to use for the same VST(i). I think that was one of the main reasons I chose SM 8 months ago; I thought it would be easier on the CPU rather than SE. cheers