nippybaynes404 ·
I would like SM to have an extra set of wireless links that worked using names insted of data flow type. 🙂 This would make my schematics look so much tidier and alot eisier to see what i am doing.
NippyBaynes404
🙂 🙂 🙂
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
nippybaynes404 ·
I would like SM to have an extra set of wireless links that worked using names insted of data flow type. 🙂 This would make my schematics look so much tidier and alot eisier to see what i am doing.
NippyBaynes404
🙂 🙂 🙂
oddson ·
Not quite clear what you're saying. 😕
Wireless connectors have to match on both name and data type.
If a wireless transmitter and receiver are in line with each other and neither have names then they match if their data types match.
matti ·
Two wireless output links that have the same datatype and different name are infact two different wireless links. When you make a wireless input with a name "x" it gets only its input from the output that has a name "x"(and ofcourse matching datatypes). That means you can do infinite amount of different wireless links.
If you need to convert datatype from one wireless output to be different on each input receiving it, you have to do the conversion after the input link.
infuzion ·
IMHO, that will cause more confusion then help: SM's connector system depends on users seeing what connector is what.
You might be able to get what you want using the Bus system though...
matti ·
infuzion wrote: IMHO, that will cause more confusion then help: SM's connector system depends on users seeing what connector is what.
You might be able to get what you want using the Bus system though...
Do you mean to say that wireless links cause more confusion? I have to disagree on that.. but ofcourse it's a matter of taste really 🙂
sunsynth ·
Hi,
i dream of a "Parts-List" where i can see (among others) which Wireless - Link belongs to which Modul(s) and/or it's counterpart(s)... And/or an automatic "find" System: On click find/show me the connected ones...
SUNsynth
P.S.: If you have a big Project it can be really confusing using Wireles links... 2 find them again after some time... 😉
So infuzions Tip (i use often 2) with the BUS Sytem is really good!
matti ·
sunsynth wrote: P.S.: If you have a big Project it can be really confusing using Wireles links... 2 find them again after some time... 😉
I haven't had problems like that so far. I guess it's all about how you lay them out. If you make wireless links that reach from the lowest level to the top, and in multiple places, it might ofcourse be a problem. I'm not telling to use only the wireless links, i think a balance of both is the best. If you do make a lot of multiple long loops with wireless links you can always write notes of the connections to the higher level modules.
If you have a big project it can be really confusing to have thousands of wires going all over the screen too 😉
Anyways, i really like the idea of having a search function or a list of used parts in a schematic.
exonerate ·
i would like wireless links that connect to each other purely on name and data type instead of the wireless in having to be below the wireless out.
i have found myself wanting to do this quite a few times,
so what i mean is if you have a wireless out on one level it can connect to a wireless link that is above it instead of just below, this is something that i would find really useful because i don't allways want it to connect to something below it.
AngularMomentum ·
I second that, Exonerate!
oddson ·
exonerate wrote: i would like wireless links that connect to each other purely on name and data type instead of the wireless in having to be below the wireless out...
A 'global' transmitter that beams to the uppermost level and then back down through all levels. That would be great! 😇
matti ·
exonerate wrote: i would like wireless links that connect to each other purely on name and data type instead of the wireless in having to be below the wireless out.
i have found myself wanting to do this quite a few times,
so what i mean is if you have a wireless out on one level it can connect to a wireless link that is above it instead of just below, this is something that i would find really useful because i don't allways want it to connect to something below it.
But then you couldn't copy modules because they would all have links with same names.
exonerate ·
But then you couldn't copy modules because they would all have links with same names.
yeah but i didn't mean that you have to give them a name, only that any link with the same name could link upwards or downwards, i think if it doesn't have a name then it should just go downwards like it does now.
so basicly what i'm trying to say is, if links have the same name and data type you should be able to link them together no matter where they are in the schematic.
an example of were i needed this was in my custom drop list, because just below the top level i have had to write a note saying if you change the height of the selector you have to change a value in the float component. i wanted it to change automaticly when the user changed the height be i could not because if i create a link out from the selector the height changes to make room for the new output, so i needed a wireless link to send the Y value to the area of the mouse over but because you can only link downwards though that perticular module i couldn't do what i wanted to do.
so only being able to link downwards actually stops you from being able to do certain things, and i also think that it would be very handy for when you have to create dozens of outputs to connect something back up to the top or higher levels.
as it is now 'in' equal up and 'out' equals down, this is not always the case.
nippybaynes404 ·
Do'h, I am so stupid as they do work using differnt names. 🙂 I dont know what i was doing wrong befroe. 😊
exonerate wrote: i would like wireless links that connect to each other purely on name and data type instead of the wireless in having to be below the wireless out.
i have found myself wanting to do this quite a few times,
so what i mean is if you have a wireless out on one level it can connect to a wireless link that is above it instead of just below, this is something that i would find really useful because i don't allways want it to connect to something below it.
I also agree with this too. 🙂
dasdeck ·
exonerate wrote: i would like wireless links that connect to each other purely on name and data type instead of the wireless in having to be below the wireless out.
i have found myself wanting to do this quite a few times,
so what i mean is if you have a wireless out on one level it can connect to a wireless link that is above it instead of just below, this is something that i would find really useful because i don't allways want it to connect to something below it.
i wish for that too sometimes, but the way it is SM forces you to make an oject model like with classes. global variables would be nice to hacve sometimes thought.
cheers
D3CK
matti ·
exonerate wrote: because if i create a link out from the selector the height changes to make room for the new output
The height can be adjusted to be smaller than the amount of inputs/outputs.
exonerate ·
yes, but then you have to set the size at a static value, for my drop list project i had a standard selector with most of the guts ripped out( i was just using it as a trigger) connected to my drop list directly below the top level. so the selector and the drop list were separate modules, anyway the selector can be changed by dragging the border to make it bigger, which is how i wanted to keep it, but if you increased the height i needed to get the Y value out of the selector and into the drop list for the mouse over to work properlly(so it covers all the area).
the thing is though either way, if i had staticly set the size, you would still of had to type in a value in the float component for the size to change,
so the only way around my problem would have been to be able to link upwards out of the selector and then downwards to where the Y value needed to go.
jobro ·
Wireless conectors is a very good asset to have at hand, but they are very confusing. What would be very good is if each connector pair has a property page with a colour selector. When you move the mouse over a connection with the same datatype + name then the connection is shown thru that the module the connection is into hilites in the colour that the wireless conector has designed. That way it is very simple to determin where a connection goes. When doubleclicking it then the corsponding scematic is shown and the module is centered into view.
minione ·
what about wireless links between modules in exe or in vst, it will be usefull for plugs that opens some his modules in new window, what do u think?
Tom7777 ·
Being able to transfer data from one plugin to another was requested a while back, im sure it's on the to do list somewhere.
minione ·
very good! hope that will be happend
oddson ·
Tom7777 wrote: Being able to transfer data from one plugin to another was requested a while back, im sure it's on the to do list somewhere.
I thought it's not possible because of the VST interface. 😕
stefan ·
oddson wrote: Tom7777 wrote: Being able to transfer data from one plugin to another was requested a while back, im sure it's on the to do list somewhere.
I thought it's not possible because of the VST interface. 😕
It's "possible", but won't work that good, since you will have an undefined latency in the data transfer (windows isn't an real-time OS after all). And by undefined I mean really undefined, since it's entirely up to the thread handling and context switching of the host / OS.
rl ·
BTW: I'm still dreaming of better navigational handling of wireless connectors. For example: - right click on a wireless receiver and select "Goto Sender" in the context menu to open the appropriate part of the schematic. - right click on wireless sender and select "Show Matching Receivers" in the context menu to display a dropdownlist of schematics with matching receivers. Select in list to go to that part in the schematic.
Tom7777 ·
I dunno im sure it's possible to a degree but it's not something i really want myself but i remember this was talked about before so i assumed it was on the list but that was a while ago and as theres no public version of the to do list it was more of a guess 😉
infuzion ·
stefan wrote: Tom7777 wrote: Being able to transfer data from one plugin to another was requested a while back, im sure it's on the to do list somewhere.
It's "possible", but won't work that good, since you will have an undefined latency in the data transfer (windows isn't an real-time OS after all). And by undefined I mean really undefined, since it's entirely up to the thread handling and context switching of the host / OS.
Might be good for green data; like a VSTi's controls also affecting other VSTs.
oddson ·
Tom7777 wrote: I dunno im sure it's possible to a degree but it's not something i really want myself but i remember this was talked about before so i assumed it was on the list but that was a while ago and as theres no public version of the to do list it was more of a guess 😉
I'm guessing I misunderstood what was said about this.
I thought there was no effective way of sending data from one VST to another except as an audio rate signal, subject to the limitations of these impossed by the host (normally: no-feedback paths).
I guess if you have two running processes they can share data by talking to each other without letting the host know they are doing it -- but then you have unknown latency problems.
I would think that means it would be a low-payoff project for the devs to undertake as you couldn't be sure when the data would be available.
Rob Belcham ·
I think it's odd that you can't use a wireless tx / rx pair on the SAME level. I've gone and drawn a huge schematic, thinking that this was allowed, and now i relalise the receivers only work if they're below i've got to go and ruin my nice neat schematic.
For example, i've wired module input nodes to transmitters, and then used receivers connected to primitives within the module to avoid having lots of bendy wires all over the place.
Surely this should be supported ??
exonerate ·
Rob Belcham wrote: I think it's odd that you can't use a wireless tx / rx pair on the SAME level. I've gone and drawn a huge schematic, thinking that this was allowed, and now i relalise the receivers only work if they're below i've got to go and ruin my nice neat schematic.
For example, i've wired module input nodes to transmitters, and then used receivers connected to primitives within the module to avoid having lots of bendy wires all over the place.
Surely this should be supported ??
AFAIR the wireless 'OUT' component can link to the same level (anywhere in the schematic, but not the same module), the wireless 'LINK' component can only link directly below (within the same module).
With your example though i would just enclose all your receivers into there own module, it's not a big deal to make them a level below. And i actually find that this makes schematics easier to read, because when you see a 'link' component you know that the receiver can only be directly below within that module.
cheers 😉
Exo
Wrote something here? To have a post removed or your name hidden, write to [email protected].