SynthMakerbillv ·
Stream goes in-I want it counted up to 4,looped and I need a green output. Is this possible, before I start having a go??
Need help with my first bit of Code
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
nix ·
no, u can't have a green output 🙁 I can sort u out with stream counters though
billv ·
nix wrote: u can't have a green output
That hurts so bad it's not funny.........pause.......pause........... . nix wrote: I can sort u out with stream counters though
Can they output a loop of numbers to green with no tick??
nix ·
nah 🙁 that's one of the serious flaws with SM- you can go green to stream- but not stream to green without a tick to sample the stream sorry, it may be possible soon with Ruby- who knows what tricks the brilliant minds here can do with that one.
The stream counters are sample accurate internally, so as long as u don't need to send MIDI, u can build a neat sequencer
I don't know what is the future of SM, and that's what it comes down to, with the things that are lacking
looks like you can't actually have a 'floatout' in code,hmm
billv ·
have seen a piece writton on "Green code", how to do it. It's in either 3 places, the wiki, the forum, or somewhere in my files. I was certain it was in one of those Optimisation OSM's going around. Been searching but can't find it.........
nix wrote: I don't know what is the future of SM
They should update it more often. They should employ someone to oversee this whole forum, process all the good stuff created by users and send it all to the wiki(which is empty, compared to the knoledge in this forum.) The same guy is also takes the serious stuff back to the SM team where they put the icing on the cake and turn them into modules, to be released in the next update, with credits to the Users who created the modules. But to them, is it worth it. How much money does SM generate each year. Enough to pay the bills? If I was in their shoes, I'd most likly do the same thing-take the engine, throw some different paint on it, add some fuel injection- and flog it for some more money. The old saying goes-""Baby needs a new pair of shoes". Later
tester ·
...On the other hand, there are projects that just evolve, no matter what, and I hope this is the case with SM. I'm doing my own work in the internet since about 10-12 years. Sometimes I'm on top of the time wave, sometimes behind it, but always on right track; never bored because of creative and new possibilities on upcoming horizon. The only thing that could stop SM from being/evolving I think - would be a dramatic change in WYSIWYG software writing (advanced software writing for everyone) ) or in a global hardware/software OS architecture (not a boom for idevices, but change like between simple calculator and advanced laptop) or human-factor related accident.
We - the users - could create our own tracker for submitting ideas, solutions, bugs, modules (like they do with rockbox - alternative firmware for pmp players), and make our library in different way. But I think, there would come a time, when feature requests would become automated with no human interaction, and folks who work around these modules would begin to feel overwhelmed by expectations and lack of compensation from 3rd parties which surely would make money on it. So right now - a forum is the right way. We talk with each other, we respect each other.
I also would not think in terms of "what was not done in the past", but rather in terms of "what can be done right now". A good example is the recent deveopment of long-time wavescope. Few weeks ago - there was no such thing here, and some folks were saying that it's impossible to make it with SM. Now - they did it in just a few days.
😉
nix ·
hang in if u like billv, the success of ur x11 is cool. I'd like to see ya 'round --typically you float or int the values in a piece of SM code, but jiggered if I know how to get a floatout; happening
trogluddite ·
billv wrote: have seen a piece writton on "Green code",
Maybe this is what you were thinking of... Green Coding It gives a way to execute a code/assembly block only when triggered, by using the analyser. I doubt it is of much help to you though - it is meant for executing code at trigger rate, not for making sample accurate triggers.
Re: Accurate green timing (apologies to those who have read all this before) Accurate green timing will not happen unless the core code of SM is completely re-written - apart from the technical problem that they operate on different CPU threads, they are conceptually very different. Green is designed to be non-time critical - it is not an accident or a bug, it was done purposefully in order to make (relatively) rare events use as little CPU as possible. I have said this many times - IMHO the problem is not that green timing is lousy. The problem is that MIDI only operates in the green domain. A blue/white stream hook into the MIDI output devices is IMHO the thing we seek. The only way to make green timing better is to remove the very things that make it so useful for keeping user interface and housekeeping tasks so economical - fast triggers will simply not work because the CPU overhead of keeping track of the triggers would quickly lead to massive CPU use. You may say "yes, Trog, but SynthEdit/maxMSP etc. can do it!" - yes, they can, because they are built around different conceptual frameworks - and if those frameworks suit your intentions better than SM, sadly, your only choice is to work within SM's limits, or migrate to other software.
This is unlikely to change any time soon because the core of SM is now in FlowStone, where these issues are less of a problem to most users. Ruby will also not change anything - Ruby is a run-time interpreted language and is much too slow to allow sample rate use at low CPU - it is part of FlowStone simply because it simplifies the construction of functions, and allows greater flexibility in data structures and graphics (still useful for SM of course, and I hope we do get Ruby eventually).
As Tester rightly says, we have to assume that we must use SM as it is, and not pin our hopes on any "wish list" - AFAIK, there is still only a single programmer (Malc) writing the code for both SM and FlowStone, and SM is quite obviously not a priority right now. AFAIK, the forum is now a completely independent community, Malc comes here only when there is an update to post - and this includes the "Bugs" and "Ideas and Requests" areas. He's a nice guy, and will not bite you if you wish to contact him directly about any concerns, bugs etc. - but he never reveals anything about ongoing development, at least until there is a Beta ready for testing.
SynthMaker was designed for building synths, and at its conception, the assumption was that only MIDI input was timing critical. It is amazing how far beyond that many people have taken it, and how many "impossible" things have been achieved, but there are certain fundamental limitations which no amount of "trickery" will overcome.
Tester also rightly hints that SM is a fantastic experimental playground, and together with this forum, makes a fantastic DSP "classroom" - but if you have a specific goal in mind, then like any engineer, you must choose the best route towards that goal, and that may not always be SM.
As the old cliche says, "Only a bad workman blames his tools." - because a wise workman chooses his tools with care.
Disclaimer) This is just my personal reading of the situation - even the moderators here are totally independent of OutSim, and are not able to influence the company in any way, nor are we party to any "inside information" - we're just here to tidy up around the place, and tell off any "naughty" people!
billv ·
trogluddite wrote: SM is a fantastic experimental playground, and together with this forum, makes a fantastic DSP "classroom"
So true.For such purpose's, it's the best program on the planet.
billv ·
nix wrote: hang in if u like billv
Yeh, I'm not going anywhere. I was just spitting the dummy out there for a while. Got to expect that from an 11 year old. h ha Guys, what about those white and blue booleans? Can I trigger a a green boolean with these somehow? Basicly, all I need is two trigger hits. One simple on and off message coming from stream. Can we transfer a simple (0)+(1) from stream to green?. It doesn't have to loop. I can feed those two triggers into a counter and take it from there.
Ummm,
trogluddite wrote: SynthMaker was designed for building synths, and at its conception, the assumption was that only MIDI input was timing critical.
i see that, but or me DSP starts with "Digital". 0 and 1. Even if it was just designed for "Synths", you'd think the VERY FIRST thing you do would be to create a solid 0 and 1 framework, so that everything runs like clockwork. Once you've established that, you then focus on the real stuff-making Synths. I want to make musical equipment Trog, not spend a year trying " to build the framework" when it already should be there. What the hell am I making Timers for?? Last thing i want to do.Love the challenge, but it's still a joke.
trogluddite wrote: As the old cliche says, "Only a bad workman blames his tools
Yeh, that applies a lot. I follow a different logic.
Give Eric Clapton an
trogluddite ·
billv wrote: VERY FIRST thing you do would be to create a solid 0 and 1 framework
I quite agree with anyone who says that MIDI Event timing should have been given greater importance (either back then, or in an update) - a solution to this is the SM "holy grail" for many people. Where I differ in my opinion is that I think the "low priority" green system is a good idea and should be left alone - putting GUI etc. on a different thread is very useful for ensuring that user interaction doesn't interfere with the audio side of things. The solid 1 and 0 framework is already there - in the form of streams - so I think the solution lies in getting a way to integrate MIDI events into the stream domain (we could then even use code/asm to manipulate MIDI data).
billv wrote: Give Eric Clapton an
He he, please not Eric Clapton! - maybe a little Django Rheinhart 😉 Quite right, a talented artist can make joyous music with a few pots and pans, or a paper and comb - but making plugins is more akin to engineering than artistic expression - you can't hammer nails in with a wine glass no matter how good a carpenter you are..
billv wrote: not spend a year trying " to build the framework" when it already should be there
SM does do whatt it "should" - i.e. exactly what the developers decided. That is the nature of the modern world - no marketing exec' is ever going to tell you what their product does not do. I do understand your frustration; there are many things I'd love to be able to make in SM but can't. My post was not meant to be a defence of the software, nor was it meant as criticism of you - just a realistic assessment of the limits that all of us face when using SM. After a long time using SM, you get to know that some of those limits are fundamental - not a case of nobody having worked out the solution, but provably unsolvable. It would be a shame if you had to move on from SM, the stuff you have made and shown here is really inspiring - but maybe it is better to admit that you have out-grown SM than to "spend a year trying" in vain. (I have no idea if that is right for you - just suggesting that it may be worth giving some thought to "cutting your losses".)
billv wrote: Guys, what about those white and blue booleans? Can I trigger a a green boolean with these somehow?
I'm afraid not - the same stream<->trigger timing issues will still apply. I wish as much as anyone that OutSim would solve this problem for us. I have seen many people spend an awful lot of time looking for clever workarounds. It may be possible to find something which, on a powerful enough machine, is "acceptable" - and there are ways that do work accurately which rely on external processing... ...but without updates from OutSim there is no SM "native" solution. 🙁
nix ·
Hey trog, Can you not call a .dll with Ruby though? Can that .dll stream a clock signal out of the Ruby component? Just wanted to ask/clarify.
trogluddite ·
nix wrote: clock signal out of the Ruby component
Possibly - the FlowStone manual has this to say....
FlowStone Ruby wrote: Clock Accuracy The schematic clock runs at 100 Hz. Unlike the Tick components which are not time precise due to their use of Windows timers, the Events system uses a different timer which is much more accurate so each 10 millisecond tick should occur precisely on time. If you have any of the DirectSound or ASIO primitives in your schematic and these are switched on then the clock will automatically switch to run in sync with the audio processing. You can then schedule events to occur with sample precise timing within any audio frame.
So it looks as if a clock could be made with good accuracy - i.e. a series of scheduled events from a Ruby output. To me, this immediately raises some further questions...
1) To sync this clock to PPQ etc. would require an input from the PPQ primitive. but that is a stream - and from what I can see all Ruby inputs are only triggered data types (Green/GUI). So I am unsure if a way to ensure accurate PPQ sync would be simple to implement. (remembering that one beat is not always a whole number of samples). 2) Processor load - as I said before Ruby is a run-time interpreted language, and not a particularly efficient one at that. The CPU load would inevitably be much higher than e.g. a stream clock. 3) Assuming that Ruby can output events so quickly, other parts of the schematic attached to the Ruby outputs must also be able to react at that speed. This also raises CPU issues, as green triggers have a lot of greedy overheads, and I have seen before that green inputs to code/asm are not time accurate (but maybe that is already fixed using the new "timer" mentioned in the manual extract above. 4) Are we actually going to get Ruby in SM? - FlowStone is a more expensive product, and the usual commercial model is that developers keep "the best bits" for their "premium" products. I have explicitly asked OutSim this (and other) questions, but all they will say is "Don't worry, SM has not been forgotten.".
Maybe someone who is a FlowStone user could answer some of these questions (the MIDI primtives are in the FlowStone components guide). As we already know, SM updates etc. are few and far between, and we have no idea what OutSim are going to do - so i stand by my opinion that we have to use SM as it is. I would not personally get seriously into a project that is ultimately reliant on new features that we may never get. I would also say that if we do get Ruby that trying to use it as a "drop in" fix for existing projects would probably not be the best way to proceed - it's likely that writing sequencer engines etc. to work entirely within the Ruby language would give much better integration with the new timing system etc. But I have never used FlowStone, Ruby or the magic new "timing" system - so I could be utterly wrong about all that!!
P.S.) To all who read my earlier posts, and especially billy. Apologies if I came across a bit facetious, cynical etc. in those posts. That's mostly because I have become very cynical and skeptical about SM's lack of progress, and old age is turning me into a sarcastic curmudgeon! I do sometimes fall into the trap of posting "How many time to I need to tell you!!!" and "I told you so" when folks are trying their best to get around these problems - but only because I have seen so many people try and fail in the past (and because it is the fate of all middle aged men to lapse into all the traits that they hated about their own fathers!!) Best of luck with your projects - I will be first in line to buy you a beer if you prove that my pessimism is all completely and utterly wrong!
DigitalWhiteByte ·
trogluddite wrote: 4) I have explicitly asked OutSim this (and other) questions, but all they will say is "Don't worry, SM has not been forgotten.".
Real ? Ha HA Ha I never forgot, my dead dog. but this does not make it alive. 🙂 sarcasm?
trogluddite ·
DigitalWhiteByte wrote: I never forgot, my dead dog. but this does not make it alive.
Too true - and as long as SM is for sale, and hence a source of some revenue, they are hardly likely to publish its obituary (which would be all over the forum in an instant).
tester ·
Outsim company profile: "silent water"? 😉 We have a saying here: "still waters run deep".
So long as you, me and anyone else can make something of SM - there will be people who want to buy it. Otherwise - other platforms.
Going back to original question. 😉 Is there maybe a conceptually different way to achieve similar end-effect (on similar or higher layer)?
billv ·
trogluddite wrote: Apologies if I came across a bit facetious, cynical etc. in those posts
All good mate. Always speak your mind. No worries. I was just fustrated. Don't worry about it.
trogluddite wrote: if you had to move on from SM,
Love it too much for that.
trogluddite wrote: The solid 1 and 0 framework is already there - in the form of streams
Yeh, It's about time I got out of the Green. It's just that years ago I tried lots of things in stream, and 99% of the time was failure. Couldn't make anything happen. A lot of Stream work seems to be pure math, and I never passed a Maths test in my life. Not once. But I'm slowly getting more confident with it. Note: Interesting stuff about Ruby and timing............
trogluddite ·
billv wrote: Yeh, It's about time I got out of the Green.
Maybe the cummunity here could help with that - I got thinking about this after tester posted his question about converting algorithms from green to stream. The problem is that many green operations don't have a simple stream equivalent - for example, the kind of array operations that are needed for holding and manipulating sequence data etc. Sadly, the MIDI timing limit is one thing that the "code/asm gurus" can't write a way out of, but 'I reckon that there are probably a lot of other things that would be simplified if there were a nice set of "building blocks" for them - something like the excellent "Developer's Toolkit" and "Missing Links", but with more focus on stream processing. I'm sure that there are loads of good examples already on the forum that could benefit from being collected together in one easy to find place (so frustrating when you know you saw a solution posted but can't find the right search terms!) I kind of use a system a bit like this at home - I use the Notepad++ utility for code writing (much more flexible editing with search and replace, split screens etc.), and I keep an archive of code/asm "subroutines and functions" that I can just cut and paste into code blocks to save writing from scratch every time. I'll have a rummage in my archive, and see if I can cobble something together to get the ball rolling.
billv ·
trogluddite wrote: many green operations don't have a simple stream equivalent
This seems to be my main issue Trog. I understand that stream is a different language than green, but if I could manipulate Stream signals like I can with Green: Jeez, I'd have a field day.
trogluddite wrote: Maybe the cummunity here could help with that
My "first attempt at SM code" was to be a real simple counter that loops. I've done this before in Visual Basic., so coding is not "completly " alien to me. But Yeh, well I'm in way over my head at the moment.
trogluddite wrote: I keep an archive of code/asm "subroutines and functions" that I can just cut and paste into code blocks to save writing
Exactly, I kinda use this method with everything. Keeps the creative flow going-you don't get bogged down doing something that should have already been done. My toolbox is loaded with "temp" stuff, so later on when I feel like, I go through the Osm a replace it all. For eg: The "if and then" thing, I got the whole statement in a module, and visually it's running from left to right. I can see the whole statement in one hit, make quick ajustments from the front panel, visual indictors show me what's going on, and there's no need to reach back into toolbox for a "greater than" or something. I guess that's called "pre-production" yeh. I know it as "prep" from being a Kitchen Bitch. Had it drilled into me my whole career. Just can't help it.
trogluddite wrote: "code/asm gurus" can't write a way out of
Thanks trog: that statement sounds like a "Open Challenge" in disguise. I'd hate to "Write off" the masters of coding though, who knows what they're capable off. We did put a man on the moon after all. I think of that everytime i hear the word "impossible"-it helps me put my feet back on the ground and focus more clearly. If any of you "coder's out there spend time on this-Thanks in advance.
trogluddite ·
billv wrote: Thanks trog: that statement sounds like a "Open Challenge" in disguise. I'd hate to "Write off" the masters of coding
All we need is that stream hook into the MIDI output driver - that's the only bit I can't see a way around. I already have a pretty good MIDI looper half finished - it uses a sneaky Reaper JS script to do the "Stream->MIDI" conversion (that's the only bit which is not "SM Native"). All the other bits; manipulating the MIDI data, accurate PPQ sync, MIDI merging and output buffering etc., are working as code/asm streams. The maximum timing error is only 8 samples - that is just because I used hops to lower CPU load, and to avoid simultaneous events "clashing". If we could just get a "Stream to MIDI" primitive, many parts of the schematic could be turned into "building blocks" for stream based sequencing etc.
martinvicanek ·
trogluddite wrote: All we need is that stream hook into the MIDI output driver
+1
Wrote something here? To have a post removed or your name hidden, write to [email protected].