From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Tom7777 ·
Hi, the wireless send recieves are great, but my idea to not complicate things is to add a new additional set which work with string inputs, now im guess some people will wonder why i want this, well basically it would allow for stuff that changes so basically no need for a multiplexer, an example of this is say you have a view changing effect bank, normally you would have to link a multiplexer to a ton of wireless links, so Dropdown List > Multiplexer (with redraw etc) > Loads of wireless links.
Then if my idea was added basically it would be the same flow however loads of wireless sends wouldn't be required as you would just link the names out from the Dropdown list and send it to the new wireless send with the string input, you would of course still require the recievers but it would make re-arranging so much easier and also no need for tons of wireless send, thats just one example which is like a wireless multiplexer in terms of use but im guessing there could be loads of other useful uses for something like this. Thanks
stefan ·
Hm, not entirely sure I get what you're after, but couldn't you use buses for this?
Tom7777 ·
No i don't think so, basically they would allow for dynamic changes of sends, when the wireless links idea first came up for discussion i had the string input in mind but they turned out a bit different, basically they would allow for super easy organizing when used in combination with busses for the audio etc and im sure other cool things. If they were added i could make unlimited things or at least fill up all the entrys i needed without having to have hundreds of wireless outs in the multiplexer, so basically i want a lower level version i guess. With the current links i cannot do what i want to do.
Acrobat ·
A few weeks ago I updated my monosynth with visual feedback for controls. Now every fader, knob and switch sends float and string name to the fake LCD, but the OSM (which was very straight and simple) got very complicated, a real mess with hundreds of green cakble all around. Probably using busses I would spend a little more time but avoid that terrible mess of links. I think a GREEN CODEBOX would solve better than anything these kind of problems, even if I'd prefer a non-code solution... or I have an alternative idea: allow wireless sends and receiver having same name when the connector type is different.
TomC ·
stefan wrote: Hm, not entirely sure I get what you're after, but couldn't you use buses for this?
After the first reading I didn't got it either, but now when I think about it
he probably means wireless sends which can be renamed dynamically
to send to different(!) receivers during runtime.
Not sure if that makes things less complicated, but it's an interesting idea
I think.
Tom
Tom7777 ·
Exactly thats what i mean TomC 🙂
stefan ·
TomC wrote:
stefan wrote: Hm, not entirely sure I get what you're after, but couldn't you use buses for this?
After the first reading I didn't got it either, but now when I think about it
he probably means wireless sends which can be renamed dynamically
to send to different(!) receivers during runtime.
Not sure if that makes things less complicated, but it's an interesting idea
I think.
Tom
Can't that be done with (wireless) buses? I must be extra daft today or something 🙂
Tom7777 ·
hmm wireless busses haven't tried that, sorry i may have overlooked somethings, still not sure about it though do you have a quick screen that would do the sending dynamically? Im gonna experiment and see if i can come up with something.
Tom7777 ·
I think i get what you mean, if you use lots of named target outs and put view inputs on each module it should work (will have to try though) but way more complex than what i had in mind with the new send/revieve but if it works should be good.
Edit i tried what you said in combination with wireless sends, however the view doesnt seem to be sending through the bus, heres what i was thinking -
WHich should work in theory but doesnt seem to, the multiplexers what i had before so ignore that bit
BasherT ·
I have encountered this issue before.
You cannot pass view data types through a bus 😠
The component reference explains at page 52:
Only the following types can be combined into a bus:
Trigger, Boolean, Float, Int, String, Float Array, Int Array, String Array, Stream, Stream Boolean, Poly, Poly Boolean, Mono, Mono Boolean, Mono4, Area, Pen, Colour, Colour Matrix.
It makes some GUI things a bit of a chore in my view.
Tom7777 ·
Hmm ok, so its not a bug then, hopefully the devs will add the function to do that or the new wireless set idea.
BasherT ·
Malc has already said that he would look into this!
[old link]
Hopefully it is something that could be done soon. I think it would be useful.
Eska ·
For dynamic changing busses it would be also good to change the" bus create" behavior . Targets with the same name should be added, currently the second target is ignored.
infuzion ·
Eska wrote: For dynamic changing busses it would be also good to change the" bus create" behavior . Targets with the same name should be added, currently the second target is ignored.
You can use the same system that the "Preset" sub-modules use (like inside the knobs). For example, the SM module Step UFO has the master preference (the little P in the lower corner) "Preset" with a value of StepLFO. So, that prefixes all the "preset names" via a wireless link, so you have a knob called StepLFO-Knob (tricky devs!), the other knob called StepLFO-Smooth, the main LFO step part called StepLFO-Sequence... I hope you see a trend 😉
Just do the same with the Bus names.
Then, you can use the "bus create behavior of 2nd ignorance" in your favor, since you can add buses together (connect 2+ into the same In), then use a single Bus Extract. I did that almost 3 years ago, & still works like a charm!
sunsynth ·
Hi Infuzion,
sounds great but... do you have a little schematic 4 us?
Walter
Eska ·
Yes, bus adding, that it`s all about, I should have said it loud and clear.
By adding busses I notized a significant increase in cpu load. (same with a "discrete" matrix). As a cheapomaniac I always try to switch rather than adding.
infuzion ·
sunsynth wrote: sounds great but... do you have a little schematic 4 us?
Sorry Walter,
Yes & no. The original OSM I made almost 3 years ago still works as it did, but as soon as I edit it, the Bus adding or something gets confused, and won't transmit the data correctly (as it did atleast). So I have no "bus adding" demo that really works. I never did like SM's bus system; it is too unpredictable, almost like dating a drama-moody girl. I can explain my arbitrary_bus_parser invention though:
[old link]
Thanks for the tip Eska!
sunsynth ·
will have a look... Infuzion
thanks anyway
Walter
Eska ·
Ahhh..got it. Thank you Infuzion.
Wrote something here? To have a post removed or your name hidden, write to [email protected].