From the original SynthMaker forum (2004–2014), with its members’ names and dates.
bootsy ·
So there are so many requests out here - what are your most wanted at the moment?
My top 5 list goes:
1. mousewheel support 2. double datatype support in the code module 3. decent convolution algo 4. proper audio resampling (customizable in quality vs cpu) 5. stream iFFT
nice weekend, bootsy
exonerate ·
Here goes mine 🙂
1. Sample accurate events (The new events system) 2. A green code component (LUA) 3. Full support for SSE2/3 4. Up sample and down sample primitives 5. A memory input to the ASM and code component
And I want it all NOW!!..............please 😇
Cheers 😉
Exo
TheAudiophileDutchman ·
... and mine 😀
1. Efficient external & internal array handling in ASM and code component 2. Full SSE2 support (including integers) 3. OpenGL - hardware accelerated graphics support 4. Export VSTi to MAC-Intel platform 5. Green code component / interface to C++
Highly recommended! 😇
TAD
angstrom ·
1: new event system , so I can make rhythmic devices
2: that's it.
Tom7777 ·
My top list -
1. Views through busses 2. New events system 3. Lower CPU for low level modules 4. Faster when making large projects 5. Green code system
chironex ·
Hmm...
1. SDK!!! 2. More advanced code component (support for all data types) 3. Soundfont support 4. Less CPU-intensive Low-level stuff 5. Better events system 6. iFFT Primitive 7. Convolution Primitive 8. Waveshaping operations for float arrays (Like Helix and z3ta+) 9. Poly4 10. High-Quality Pitch-Shifting Primitive 11. Physical Modeling modules (more than just karplus) etc...
Hey, no one said only 5 🙂
gregh ·
angstrom wrote: 1: new event system , so I can make rhythmic devices
2: that's it.
that's it for me too
TomC ·
1. SDK 2. Green code module 3. Array/Mem input for code module 4. Export for Mac 5. Busses for all connection types
Edit: Yeah, forgot the lockable module 🙂
aliasant ·
1. Export to Mac intel 2. Convolution Primitive 3. OpenGL - hardware accelerated graphics support 4. A way to export vst to Mac intel......... 5. The new Event system
Did I mention export to Mac Intel??
Acrobat ·
The new primitives I dream of:
1. A primitive named "Sambean" that outputs perfect DSP processing 2. A primitive named "Oddson" that ouputs 2D/3D math, physics and data mangling 3. A primitive named "Exonerate" that outputs the most convenient solutions for every complex audio manipulation purpose 4 A primitive named "rl" that outputs perfect synthesis and emulation of software/hardware devices 5. A primitive named "Myco" that outputz stanning audio proocessing for evry needz
then,
6. A primitive named "Infuzion" that outputs the ASM version of the code outputted by the primitives 1,2,3,4,5 7. A primitive named "Stefan" that says with a vocoder "I'do this other way" and gives the better, more reliable solution for the ASM outputted by no.6 8. A primitive named "TAD" that gives another solution if you want things work exactly good as 6 or 7, but looking smarter, rare like a VCS3 and that tastes a bit "out of this world" 9. A primitive named "TomC" that gives another more solution if you want things work exactly good as 6, 7 or 8, but looking definitely cooler
And finally,
10. A primitive named "Malc" that outputs new primitives with the ASM outputted by no.9 and place them a mouse drag away.
(sorry if I didn't mentioned other forum members, there are a lot more to mention at every point for sure...)
with love, Acrobat ------------------ Oh I forgot,
11. A primitve named "Balthor" that outputs just a green string that claims to have written all of the above primitives and maybe the software itself!
Nu Audio Science ·
1 SDK 2 Lockable code component 3 Events system 4 Middle mouse wheel and button 5 C++ exporter (never gonna happen but would cover optomising and Mac Linux ports)
NAS
angstrom ·
oh hang on ...
3: search schematic
theun ·
My wishlist
1. green code/asm module A real showstopper at present.
2. array input for stream code/asm module Also quite an essential feature that is missing.
3. SDK If the mountain won't come to Muhammad, Muhammad will go to the mountain!
4. export for mac Mac marketshare is growing worldwide while ms in the mean time has no clear vision on professional audio support in future OSs. So potential customers for products made with SM may more and more often use a mac
5. more stable event system At present the awkward event system is a crucial negative selling point to a group of potential Outsim customers.
PS my birthday is in July ...... I almost can't wait anymore 😉
MichaelBenjamin ·
1. accurate green event system 2. module primitive sdk 3. easier wave file support with sustain loop, velocity zone and wave write
TomC ·
Acrobat wrote: Oh I forgot,
11. A primitve named "Balthor" that outputs just a green string that claims to have invented
all of the above primitives and maybe the software itself!
Fixed!
Tom7777 ·
Arg how could i have forgot lockable modules add that to the must have list also, since people are listing lots of things some lower listed things would be -
Midi player,
Convolution
Buffer based modules so we could make granular delays/effects like in reaktor for the non coders here
SDK
Audio reverser, can set buffers storage etc in samples
Busses support all data types
Mac AU export option
Smoother array shifting/warping etc
Soundfonts, mp3, aiff, ogg and various other format support
Edit - Non SM stuff but related 😈
Forum gets fixed
People use the search feature
People post under the right forum areas and stop posting help questions in the general section etc
infuzion ·
OK, here are mine:
1: No drama No SM crashing, no issues with hosts, no issue with FL OSMs being different than SM OSMs, no weird tricks just get get things to work, no broken parts (like the bus), no forum issues, etc. I just want things to work right, & not to worry. Sounds like a bug-issue, well it is. If SM1.1.0 starts to crash as much as older versions, I'll just give up on SM. If I can't use it in the hosts I use or (most of) my customers, SM is pointless.
2: Fast & accurate editing Hard to de-bug if I'm looking for some broken connection or wrong primitive when you have 10,000 modules. (repeat of schematic searching & item-tree, & have same schematic open in 2+ windows, better toolbox viewing, my large-file=slow-editing bug, etc). An advantage of editing regular text languages (C++, BASIC, etc) is that you can usually use any text editor, have various shortcuts to insert blocks of code, auto-correction/formatting, search for a keyword across several files, auto-doc, etc.
3: Professional-level results (optimization, SDK) From the toolbox, SM's modules take up more memory & CPU than needed. While there are some good optimized versions around, it is a pain to have to download them, test them, copy & paste them into my project. SM should ship with fast code. In fact, I have no SM VSTis & only 1 VST (the new vowel-effect) in my Live's VST folder, since I find that there are other rich sounding VSTs (Atlantis, Helix, ZebraCM) for half or less of the CPU that almost all the SM VSTs I've tested recently. Even newer SE synths whoop SM in CPU usage (oxytocin, ANGSTkILLERmini), likely because of SE's SDK... & speaking of the SDK, that is the only way I see that SM is going to get 64bit/full SSE, green code/LUA, & other things SM can't really handle within the 6 months. Maybe not, but then advanced users will have to quit their crying about missing features since they can make the features themselves.
4. Intel OSX/Linux support I don't have hard numbers, but I think companies that have OSX support sell around 20% in that OS. I don't expect the current Outsim crew to become expert enough in different OS platforms, this is more like a plea for new devs to help out.
Tom7777 ·
Big +1 for the first 3 for sure infuzion
Not a linux user and have not much idea about how it works but if it runs VST then one would expect SM stuff to work also.
Nu Audio Science ·
As of the latest builds of Ubuntu and so on SM now works flawlessly under WINE and i am even being told by some testers that the CPU usage is less than the same PC running Win 😉
NAS
chironex ·
Of course, I completely agree with everything infuzion has said. Even though SM is far more powerful and easy to use than SE in gazillions of ways, it lacks an SDK, it's unstable (The other day, I was attaching a float wire and SM just quit, no error sign or anything. Just, whoosh!), and hogs CPU like it were drunk. I can feel in my blood that many of these problems will be solved in the (2-year?) future, but for now, being able to write a true, big-business style
It's not that I'm not thankful for 1.1, it's just that the devs have a lot to work on for 2.0.
infuzion ·
Nu Audio Science wrote: As of the latest builds of Ubuntu and so on SM now works flawlessly under WINE and I am even being told by some testers that the CPU usage is less than the same PC running Win
Thanks for that insight NAS!! WINE-VST is good enough for me; as long as my VSTs work in Receptor I'm happy.
chironex, I'm hoping to sell mine for
Tom7777 ·
Imo for 00 the synth would have to be very efficiant on par with the popular synths which some cost less than that and also offer various things i found cool, thats a bit high too imo. Maybe its me but any SE or SM synths of effects in that price range would have to be something pretty special 😇
chironex ·
Infuzion, I've never actually seen any of the synths you make. DO you have a website where you sell them? Where do you display them?
jobro ·
So what do I want then?
1. More components handeling strings / numeric data more easily.
2. Lockable modules. Nuff said about that.
3. Export module to SynthEdit Module. No kidding here this would be utterly nice since I use both platforms and I tend to prefer SE's way of handeling 3rd party components. So this would definitly be a big buck for the back if this could be arranged.
4. Link surfing. Give us 2 adress fields besides the Developer button. Give each primitive / module an adress. Then as you change object so does the adress. The first field is for the adress it has, the second is for the first target the object is pointing towards. Say a VSTI takes in data and points it to a MIDI to Poly object. Here is an example of how such an adress could look like:
SM://Synth/Oscilators/1/Waveform/oWave.lnk
Ofcourse this wouldn't be useful without the following feature:
5. Split screen
Getting data sent through links is sometimes a pain to do. You name the links proper but nothing gets through. So by using a split screen you could easily see what the source link is doing, and what link it connects to, and when. Think a frameset on an internet page. It's much the same way you finetune these to show what data you want to show. You could either set the source locked and manualy select the target, or oposit way around. This way we'd have a quick and resolute way to debug and move around in the synth structure.
Whew quite a long one, but mostly the ideas are useful.
rl ·
> 3. Export module to SynthEdit Module. how about exporting as VST dll and using that from SE?
jobro ·
That's one way one can do it, but it is easier to link in SEM's rather than VST's in SE projects. SEM's comes with assigned outputs / inputs that lets you controll the result more rudimentary than if you had to take it via a VST plugin, who doesn't have the capability onboard from the start. And SE doesn't recognize or give out parameter contacts on VST plugins used which means that you need to use MIDI CC's to define the parameters you want to alter, and you have to know what parameters are available and how they are allocated in the MIDI CC table. Many comes prepared, but many comes undefined.
Take a look at how SE represents a SEM (left) contra a VST plugin (right).
Tom7777 ·
I doubt it will ever happen jobro (the SE module thing) it's like the whole reaktor not exporting vsts theres something to be gained by restricting certain things sometimes for programs, just saying how it seems, SE seems to be more cpu efficiant and steady when building so everyone would probably just be rendering out interesting stuff they couldn't make in se and use them in SE projects with other 3rd party modules etc. If SM improves on certain things there would be no need for something like that imo but if not it would be cool for developers but i can't see it ever happening. 🙂
Nu Audio Science ·
Seems like it would be a total waste of time to me Synthedit is much more efficient than SM Synthedit can do virtually everything SM can do Synthedit is easy enough to write SEMs for
Basically in reality Synthedit is the much better package at the moment so it would kinda be like allowing a DVD player to play Betamax tapes
The only reason i'm still using SM for now is that i can do funky things with interfaces that isn't possible in SE but that is only eye candy
NAS
endziu ·
hm. almost nothing to add except maybe: OSC - Open Sound Control? that would be cool 🙂
Neptune ·
For me it would be enough to get an update of the SM CM version so i could get rid of the long loading time.
Maybe this could also bring some musicans back on board.
About the SE thing. Lets rename SynthMaker to SynthEdker 😈 😝
Tom7777 ·
For me it would be enough to get an update of the SM CM version so i could get rid of the long loading time.
Why not just buy SM you seem to be using it alot 😉
AngularMomentum ·
angstrom wrote: 1: new event system , so I can make rhythmic devices
2: that's it.
+1
IndiQa ·
SoundFont : Load/Play(aka screw around with)/Unload Component(s).
And all that other stuff everybody has mentioned.....
SNORK!!! 😮 😝
bootsy ·
bootsy wrote: 1. mousewheel support
A big bump on this, so much users are missing this feature ...
TomC ·
bootsy wrote: 5. stream iFFT
Time for a bump, especially because stream FFT was never mentioned!
Prost!
rl ·
The SDK of course!
(At least that's my most wanted feature request)
Skål!
TomC ·
rl wrote: The SDK of course!
(At least that's my most wanted feature request)
Skål!
Yep, SDK would solve the FTT and iFFT problem nicely. I have a killer application here just waiting for the Fourier stuff 🙂
Cheers
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker