Order markers on wireless inputs

infuzion · 6 Nov 2006

My problem with using wireless is that you can't tell the source of a said receptor is... like you can have a Font reciever labeled "Label", but you don't know how far up it's transmitter is or where it is unless you poke your know in every single module.

oddson · 6 Nov 2006

My problem with using wireless is that you can't tell the source of a said receptor is...

There have been lots of similar statements, so I guess there's something to them. But I've gotten used to using them for 'global' type variables and as program control for triggers. And to keep schematics organized but still readable. I definately think you can overdo them and then everything gets harder, not easier. But with some common sense it's pretty easy to keep track of them if used properly.

But there is no way to know the order data will flow to them unless you remember what order they were made in. I think this is a modest change that would alleviate this problem.

I would like to see another type that beemed data up to the top level and then downward from there (someone else suggested this one) - a kind of super wireless output. This would be great for trouble-shooting stuff multiple levels in that needs the GUI to test - for one.

I'm mostly pleased with the wireless system as it is now, however.

Duncan · 6 Nov 2006

Good suggestion.

oddson · 7 Jan 2008

Came across this tonight... I still think it's needed so... bump.

electrogear · 7 Jan 2008

Maybe it would be a good idea to be able to right-click on wireless inputs and have a 'go to source'?

oddson · 7 Jan 2008

That's also an idea that has been suggested. Mine is not to help navigation as to allow you to determine the actual processing order.

Currently you cannot tell by visual inspection what order a set of wireless receivers get their messages. It's still not a biggy but I think it should be considered again.

infuzion · 15 Feb 2008

+1 I think wireless connections cause too much CPU, & I'm considering going back to 90% regular wired.

I've noticed that in the Multi Stage Modulation Envelope there are basically 3 main arrays: X, Y, & curve. They are used in several sub-modules: * Left-click/drag * Right-click/menu * Presets/error-checking (fed by the above 2) * Display/more checking (fed by the above 3) I had re-configured them to use wireless to be more readable. But now that the modules have become more complex, & now I'm testing them alot, I notice slight lag & errors caused by the wrong data randomly arriving at the wrong time. It could be the the wireless-arrays data arrives at the Display first, then the Presets (causing the Display to re-ping from updated info), then feed the Left/Right click third (causing both the Presets & Display re-update). This means I could have 3 times the updates I don't need.

I could mis-understand how green data works, but I am very concerned that wireless is counter-productive.

Acrobat · 15 Feb 2008

+1 with a reserve: it needs a "off" setting or it will invalid older OSMs wireless systems...it could be, reasonably, the "0" value.. 😉

infuzion · 16 Feb 2008

Acrobat wrote: +1 with a reserve: it needs a "off" setting ... the "0" value.. 😉

That is a good idea...

Acrobat · 16 Feb 2008

infuzion wrote: Acrobat wrote: +1 with a reserve: it needs a "off" setting ... the "0" value.. 😉

That is a good idea...

it's just a "backward compatible" warning, I like a lot the basic idea, it will solve many "ideas and requests" in one shot! For example, imagine how "windows" project will benefit.... 🙂

infuzion · 3 Mar 2008

related refresh bug: [old link]