Wireless connector naming and other strategies

[RJHollins]

Hi GANG,

I'm trying to better understand working with FS, and hopefully improve my schematics.

I find that from project to project, there are many similar functions that, once designed as a 'sub-module', can be easily inserted and used from one project to the next. [old, common concept that I'm mindful of].

But something came up the other night that had me pause and wonder about.

Here's an example about my MIDI projects.

Within my main schematic, I have FS 'modules' that house individual components that contain graphics, knobs, buttons, sliders, etc, along with all the function controls that the module performs. There are usually several of these modules that, separately, are housed within the 'main' module.

Back into these individual modules, I'll routinely have several 'connectors' [often times 'wireless'].

Lets say this is the LOW band of an EQ. [other modules will house the MID, and the HIGH band].

Each of these modules have connections for a MIDI CHANNEL [along with [CC] links]. Early in my design and naming of connectors, I had specified that [inside this module] the wireless name was 'LowFreqMIDICH'. The other modules used similar naming conventions for MID and HI.

No big deal ... they each worked ... no problem.

However, the other nite playing with a new schematic, I pulled in a 'template' that I had used before, and customized it to the specifics I needed ... but I didn't change the wireless names. I made several of these modules [with their specifics], but they all shared the same wireless naming. Interestingly ... they all worked independently as they should. I know this should not be a surprise, as the wireless [LINKS] were at proper 'levels' in the schematic, and each module is it's own domain.

My question.

Have I gone too far in the naming protocol by using unique wireless names [connectors] ??

I know this is tough to answer without seeing specifics, and there are things to be mindful of. But I'm looking at a couple of things here.

1. Me keeping track of all these names, and to be sure all links are correct.
2. What is the impact when the schematic is compiled into a VST or EXE. ??

Obviously ... if in the example I used 'MIDICHANNEL' as the common wireless name, kept things within their respective FS-module, it would be many things that I'd not have to deal with every time. This would be helpful on many levels [including user error]

But the other thing ... what impact these different connectors have on the final compiled code that share the same name, rather than a individual name ? I know these are separate connectors anyways [as they need to be] ... but I wondered ... does this have any significances ??

Hope this made some kind of sense ... thanks for any enlightenment

[tester]

As for wireless connectors. Besides the names - it is good to to set manually connector type, otherwise it is set automatically and... these automatical things work sometimes weird when doing copy/paste operations. Sometimes they stop to work, and sometimes they work with something inexisting. However, to emphasize - these are rare cases.

Names can be the same for different connector types, and they will work separately, because wireless is made of "type" and "name". Now - these humanized IDs are only on schematic. I guess when recompiled - they are just relabeled into some numeric form needed on the protocol side.

Third thing to pay attention to is - cross-interference between "wireless out" and "module wireless out". Either one works or the other, but not both (and maybe sometimes both as an result of error?). Anyway - This relationship can again confuse you when for both types you are using the same names.

Fourth - sometimes it is useful to pass values through either arrays or buses. This limits amount of names.

[RJHollins]

good points tester ... thanks!

I know I might not have been too clear in my post ... but another thought on this ...

With a connector representing the INPUT to a section of the schematic and thereby a possible subroutine ... here's another aspect of the question.

I would assume [not for sure], that what may be a type of 'sub-routine' that parameters get passed in and out of ... the INPUT name would define that sub-routine. When compiled, and data passed onto the INPUT [name] would be a single section of the compiled code [I think].

Now ... say there are duplicates of this sub-routine, but the ONLY difference is the INPUT connector name. Wouldn't the compiler see this as 2 separate routines ? and because of the different INPUT name, compile this as 2 separate call sections ???

I don't really know ... and part of why as ask.

[Nubeat7]

cross-interference between "wireless out" and "module wireless out". Either one works or the other, but not both (and maybe sometimes both as an result of error?).

how do you mean this? if i have an outup and i connect a wireless output it send all levels down inside this module,
when i also connect a wireless module output it sends all levels down outside this module so where should happen any interference then? - this is a technic i often use if i need the signals inside the module and outside the module

in general this is the only case where you can use one name for 2 wireless outputs (because its still the same source, the
y just send it to different roots ( can i call it like this? )) otherwise you really need to know what you are doing, this is more dangerous using wireless module outputs because these signals are sent to all modules outside the source module!
if you have a sender one levl up with the same name you get in trouble, while a wireless output signal always stays inside the module which also can produce conflicts when a wireless signal from some upper level has the same name...

so in general i think unique names are much more secure.

[MegaHurtz]

I guess it works by putting up an in code pointer. (blind guessing) so it gets defined and then called upon several times. No big deal I'd say. Also it may well be more efficient than pulling a variable through multiple code blocks. I assume it does, and seeing the DSP is pretty well optimised, i'd see no reason why not. But I didnt write the program

[tester]

Sometimes such sort of solution works, and sometimes one type of link, when named - disables second type of link. I remember that it was independent from manually defined connector type, so I'm surprised that this little schematic works.

[Nubeat7]

thx tester

1. i would recommend not to do this, 2 sources 1 name, also if it works somehow its confusing


2. i think i found some bug relating also to this thread
viewtopic.php?f=2&t=2334

cut the wireless module output (cntrl+X) and put it back (cntrl+V) - see what happens the old cutted out connection is still here somewhere and gets added to the result you can cut and include both wireless senders and it always adds one more you can seee this effect also when using the tab to follow the connections only when you reload the schematic it gets refreshed and you see only the 2 wireless sources with the tab..