Attempting a Fader Send at Any Received Note

I'd like to create a fader that will send its setting (the second byte) whenever it receives a note on. This is to use the same channel strip in different combinations with other instruments.

In other words, MIDI ch 1 routes to a fader set to CC 7, 60 (note on, sends CC 7, 60) that is routed to the channel strip. When I play MIDI ch 2, that is routed to an entirely different fader set to 90 (note on, sends CC 7, 90) leading to the same channel strip.

Without this ability to send the setting as prompted by a note on, the channel strip keeps the previous setting no matter the channel. I have to manually adjust the appropriate fader to to re-send.

I thought Bang 2nd Fader was for this purpose, but I can't seem to crack it.

This is a bit confusing - or maybe I'm just tired. But it would help if rather than detailing what you're doing in the environment, you would detail what it is you're trying to achieve (musically).

From what I can get from your description, I wouldn't use faders but transformers, which have the ability to copy the incoming event and transform the copy - so you could keep transmitting the data but also generate a new event.

Imagine a channel strip with a VI solo legato violin. If you play it by itself (a true solo) on channel one, you want it loud.

If you use that same channel strip in an ensemble on channel two (triggering numerous other instruments), you want the solo violin lower, so that it blends, adds focus, but doesn't speak too much over the other instruments.

The most obvious work-around is just duplicating the solo violin over as many channels strips as necessary and setting them independently. I've never liked redundant channel strips, personally.

As David says, transformers would work. The pinch is that they need to be double-clicked, opened, and adjusted. For a static setting, fine. Mixing, not so good.

Basically, I would like a fader to send its value whenever it receives a trigger message. This would be like a "Send Selected Fader Value" key command, without the need to select the fader.

Fader receives specified MIDI message. Fader re-sends its current value.

This is a "I thought it would be easy" moment.

As David said, you don't need actual faders to accomplish this. You mentioned specific values for CC#7, so in theory all you'd need to have are two transformers: one that's programmed to output your CC#7 = 60 upon receiving channel 1 info, the other one outputting CC#7 =90 upon receiving channel 2 info.

I know you dislike redundant channel strips, but I think that your approach (and I say this most respectfully) is your biggest obstacle. In any event, I've attached an environment that essentially uses one transformer to do the trick. I think does what you want. When you output Ch. 1 from your keyboard it will send a single CC#7=60 upon receiving the first note-on. When you send from Ch. 2, the first note-on will generate a single CC#7=90 command. It's programmed not to send redundant volume events.

You can use the two faders to set the values for the Ch. 1 & 2 volume values. This way you don't have to open up a transformer and reprogram the fiddly map in case you change your mind about the CC values you want.

There's also a switch that forces the output to Ch. 1 regardless of input channel (which I thought might be useful), and an on/off switch.

See if this works for you.

Channel to Volume SKI v1.0.logic.zip

Plowman weeps for joy as he hits channel one, plays a note, and watches his motorized fader leap in confirmation, then hits channel two and sees them shift again.

Copious tears of gratitude for the Once and Future King Ski-freaking-Daddy, and a here's a virtual chin-scratch for happy Boing.

Now I must ponder out this Environmental mentalism and study the laws by which such trickery is foisted on the human ear -- in particular, the way it just sends one CC 7 message and then pipes down. The best I had hoped was a clunky parade of unneeded bytes, whose bandwidth MIDI could ruefully tolerate.

Thanks to David, his forum, and this great work by Ski.

Now I must ponder out this Environmental mentalism and study the laws by which such trickery is foisted on the human ear -- in particular, the way it just sends one CC 7 message and then pipes down. The best I had hoped was a clunky parade of unneeded bytes, whose bandwidth MIDI could ruefully tolerate.

Cheers, Plowman! Let me know if you want a walk-through of the wily ways of my environ-mentalism.

-=sKi=-

Fascinating. You have cracked the mystery of MapSet for me, an option under a Transformer’s “Status” output that I never understood or used. This allows me to adjust a transformer’s mapped value without opening the actual transformer, which really was the nut to be cracked.

Inventively, you’ve got a diagonal connection in “ Note Channel --> Fader” that triggers the respective map values based on MIDI channel numbers. So the MIDI channel number selects the first byte, and the value of the second byte is hand-set by the faders.

And the reason there is no parade of redundant CC’s is because “Filter Duplicate Events” is checked, so that a new event will only be sent when the fader has been re-adjusted (hence, no longer a duplicate).

Am I correct that “Splitter/Test” is just duplicating the signal? It seems to be adding “0” in the channel column, which doesn’t do anything (I think). In this case, a monitor could be used. But the object is probably a vestige of some previous use.

Bully for you, I say. Bully.

No secret of my mentalisms are safe from you, Grasshopper.

The Splitter/Test transformer does two things. First, it provided me with an easy way to change the channel from my controller into Logic. (My setup doesn't let me easily access the programmable parameters of my keyboard controller). More importantly for this application, it acts as a simple MIDI mult (or signal splitter) and could be swapped out for a monitor or ornament. You could even clear the "add" field in that transformer so that it does nothing but act as a splitter.

One split goes to the middle monitor and from there to the "Force Output to Ch. 1" switch. This routes incoming MIDI data either directly to the sequencer input (via the monitor on the right) or to the transformer which actually forces Ch. 1 onto the data. With the Force Output switch off, the data basically goes straight through the circuit and into Logic.

The other split from "Splitter/Test" goes to the transformer which looks only for note data and converts it to CC#7 data. All other data that enters that transformer would be routed to the bottom and unconnected output of that transformer. So this provided a bit of separation of church and state for the "thru" data and the generated data.

I'm really pleased that this is working for you. Post back if you find any problems with it or want modifications.

Cheers!

Ski

To my opinion all that can be optimized using one transformer only ( I did not had time to test SKI's version which probably adds additional features and is useful for sure ). The CC7 values can be set directly in the transformer mapper. Of course two additional "Numerical faders" can do that as well if you want to create a "Frameless" window box etc. As you note my Num faders do not need any additional Mapset transformer gear.

http://img525.imageshack.us/img525/7323/chlev.gif

Ch. to Level Vacheto v1.0.zip

Oh oh ...

http://a.espncdn.com/photo/2008/0430/box_g_ali_liston_300.jpg

To my opinion all that can be optimized using one transformer only ( I did not had time to test SKI's version which probably adds additional features and is useful for sure ). The CC7 values can be set directly in the transformer mapper. Of course two additional "Numerical faders" can do that as well if you want to create a "Frameless" window box etc. As you note my Num faders do not need any additional Mapset transformer gear.

 

http://img525.imageshack.us/img525/7323/chlev.gif

LOL shiver but no, no boxing gloves need be donned; I don't see any reason for this to get competitive. IMO the goal of posting these things is to help people out and be as educational as possible in the process. Hopefully we'll maintain that vibe in this discussion. It is my opinion that there is no right and wrong way to program in the environment. Some approaches may be more elegant than others, or simply different. Considering past history here, that's all I'm going to say for now on the matter.

Scandor,

Yours takes an interesting approach using different techniques.

I'd like to suggest that you download my environment so that we can compare notes. For one, I see that your programming outputs a CC#7 for every note that's played. This is one of the reasons that I used multiple transformers -- to prevent redundant CC#7 data from being generated and thus recorded.

Having seen your environments before and read your posts, I believe that "optimization" is important to you. And of course that's good programming practice. My approach when posting environments, however, is to make them somewhat transparent so that the inner workings aren't such a mystery.

I'll have to look more into using Sysex faders to ouput data such as meta events. That's very consolidated programming, for sure.

I can see this is child's play for you folks. I sit and learn.

Indeed, Vacheto's environment seems not to need the "Mapsetter" object. Ski's other objects lend functionality and bypass-ability. Ski, does your Mapsetter serve a purpose I might be missing?

Got it on the Splitter / Test object. My main controller is an Elka MK88, on which 16 neat buttons are just above the keyboard. I'm mortified when I go master controller shopping. I come back to my Elka and whisper, "Please don't die."

I'd like to bring it all back to music now. I'm an inveterate mixer of string sounds for orchestra. Rarely do my sustains consist only of one patch. (I'm sure we all do this.) But tweaking every component of the sound is tedious, and duplicating the channel strips for every sustain iteration is a sprawl.

So this is a directly helpful, musical tool. I know it sounded obtuse and unnecessarily complicated at first, but for my purposes, it's quite elegant.

I've encapsulated Vacheto's three-object render into a macro, and now it can be freely cut and pasted into pre-existing Environments.

Indeed, Vacheto's environment seems not to need the "Mapsetter" object. Ski's other objects lend functionality and bypass-ability. Ski, does your Mapsetter serve a purpose I might be missing?

The main differences between our environments:

SKI

PROS: bypass function, non-redundant CC#7 data, additional function to force the input into Logic to always be on ch. 1

CONS: programming not "minimized"

VACHETO

PROS: minimized programming

CONS: no bypass function, redundant CC#7 data (a CC#7 event is generated with every note played)

Vacheto is generating the MapSet data directly from within the numerical faders by using a special type of fader called "sysex faders". This is a neat trick that allows for consolidated programming. So the output of his faders send exactly the same kind of data that I generate, just in a different and more programming-consolidated fashion.

Using a transformer set to MapSet makes for very quick programming of mapset data (which are meta events 122 and 123). Vacheto's use of sysex faders to output meta events, and requires more actual manual programming to accomplish.

My main controller is an Elka MK88, on which 16 neat buttons are just above the keyboard. I'm mortified when I go master controller shopping. I come back to my Elka and whisper, "Please don't die."

I so hear ya. I'd love to get a CME controller because their weighted-action boards feel great, but software-wise they suck (I'll spare you the story). So I continue to use my A-80, and I have another one in the garage to use as a parts cadaver in the event a key contact or other component goes balmy.

I'd like to bring it all back to music now. I'm an inveterate mixer of string sounds for orchestra. Rarely do my sustains consist only of one patch. (I'm sure we all do this.) But tweaking every component of the sound is tedious, and duplicating the channel strips for every sustain iteration is a sprawl.

Gotcha!

I've encapsulated ---> Vacheto's <--- three-object render into a macro, and now it can be freely cut and pasted into pre-existing Environments.

And that's the thanks I get?

(j/k)

Yes, a heartless, utilitarian move on my part.

But the joke is on me. After copying over a macro of Scandor's work, I thought I'd just duplicate those faders and reset the channel from 1 through 16, just for a template. Ho ho. Now I realize that he used deep programming skills. I'm thinking, "How the heck does one fader set this and another that when they are identical according to the Inspector!?" And ski's last post explains it.

At this point, Grasshopper prefers hopping into the luxuriant grass of music instead of the arcane thicket of programming. Yes, even *I* refuse to get too involved in an Environment template.

Scandor, if it's not too much trouble, I'd welcome a template of faders 1 through 16. I'd say "channels 1 to 16," but apparently "channels" are so yesterday.

"Heartless" doesn't begin to describe it.

But wounded though I am, Grasshopper, I must tell you that those faders are not identical. See (with your compound eyes) that if you 2-click on the word "sysex" in the output section of each fader you'll see (with your simple eyes) that the value of meta event 123 is different in each.

Yes, I studied insect anatomy as a hobby. Go figure.

Oh, and if all of those redundant CC messages that Vacheto's environment creates bothers you? Ask Vacheto how to prevent that from happening. See, there's something to be said for having multiple transformers to do this job, but I'll leave it to Vacheto explain it all to you.

And with that I'll bid you a hearty harumph! and a good night.

Scandor, if it's not too much trouble, I'd welcome a template of faders 1 through 16.

It was not trouble cause I still use one transformer only and duplicated the "level" assign boxes in the new version. All is packed in one complex Macro. Screenset 1 shows the tool as float, Screenset 2 opens the Click and Ports so you can unpack the Macro and see what's new. The only thing is I have re-programed Meta event 123 for each "level" assign sysex fader. M123 controls the Mapper position while M122 assigns the Mapper value according the Num fader setting. By the way there is a stand alone environment layer with the tool so you can easy import this layer to another projects etc.

Ski, thanks for the CC#7 duplication remark ! As you pointed I'm a fan of the very optimized schemes. I just fixed that ticking the "Filter Duplicated Events" in the transformer.

Apart of the topic, these CC#7 are not harmful cause they are fixed values - according to my deep Environment tests, Logic can pass thousands of messages depending how you manage them. In our scenario it is easy to filter that using the transformer option I have mentioned but in some cases you must choose between non-harmful events (say note offs) and serious amount of Environment objects to fix the problem. In this sense I prefer to optimize the scheme and use less objects as possible regarding the Macro size limitation etc.

http://img132.imageshack.us/img132/1862/chlev2.gif

Ch. to Level Vacheto v1.1.zip

Ski, thanks for the CC#7 duplication remark ! As you pointed I'm a fan of the very optimized schemes. I just fixed that ticking the "Filter Duplicated Events" in the transformer.

Right. Non-redundant data was a feature of the environment I posted.

Apart of the topic, these CC#7 are not harmful cause they are fixed values

Well, no MIDI data is really "harmful" (is it? ). But without filtering the duplicates his tracks would fill up with redundant CC#7 values on all different channels (hence my including the "force to ch. 1" function). So for editing (especially in the event list) I think filtering duplicates is the right approach. However, there is one reason why having duplicate values could be useful, but I'll save that for another post.

Going back to work now.

But without filtering the duplicates his tracks would fill up with redundant CC#7 values on all different channels

That's correct, that's why I fixed it by ticking the "Filter Duplicated..." box in the transformer. Thanks once more time for the note !

Last night I did have time to think seriously of this scheme - the only reason, I came into the topic was to show an alternative and optimized version of the scheme where my focus

was the "Copy Matching Events" transformer template and using the Sysex Faders as control message containers (in our scenario Mapper controllers). Such optimizations can be useful just as info for other Environment scheme creation I think. This is probably useful for Environment developers mostly. I have created a Logic Studio Environment Object Sizes

list which may be useful for people who are interested from the "deep" Environment and non-documented things. Get the list from the Attachment. The list gives a major idea of the object sizes in bytes, so the developer may decide which objects to use to make his scheme most optimized. For instance when possible use a Fader object "as transformer" (718 bytes) instead of Transformer (978 bytes), or use an Ornament object as "Y" cable splitter (698 bytes) instead of Monitor object (1202 bytes) etc...

Logic Studio Environment Object Sizes v1.0.zip

Thanks for sharing that data. It's very interesting, but it also confirms my suspicion that there's not much reason to be concerned about the size of individual environment objects. It's very rare that environments get to be so complex that memory conservation needs to be an issue. IMO, environment programming for 99% of applications needs to be -- in this order: functional, flexible, transparent, nice to look at.

I just can't imagine that Logic's performance is going to suffer because a programmer decides to use a bunch of ornaments (698 bytes) as MIDI splitters instead of monitors (1202).

Think about it... if someone creates a song with a very large track count, each channel strip (according to your data) consumes 954 bytes. A song with 256 channels will consume less than .25 megabyte. I've never seen any documentation or forum posts where someone recommends reducing the number of unused environment objects (or channel strips) to optimize Logic's performance. So I'm not convinced that there's any need for concern about being ultra-compact when it comes to environment programming. After all, it's not writing code.

It's very rare that environments get to be so complex that memory conservation needs to be an issue.

Not really regarding the Macro size limitation. As it is announced in the Logic manual it is 100, 200 objects depending on the object sizes. In lots of my Environment tools when I have exceeded the maximum Macro size a prompt says "The Macro can not packed cause too many objects" - something like that, so your creativity just gone and you had to think how to optimize your scheme. In this sense the Object Sizes list I provided is very helpful.

In the pass we tried to determine (with the great enviro man - Dave Eager "Oink"), what's the actual Macro size limit in bytes (not in objects) during the L5,6,7. As far as I remember our result was about 32 650 bytes - not so much regarding the old object sizes ( we created a similar list ).

When Logic Studio was released the first thing was to test if the object sizes are changed - yes they were in Logic 8, and much more optimized which was promising...

Let's finish with the app history and announce the very GOOD NEW I just discovered .

The object size list I provided is from the Logic 8.0 probably and since then I did not make any Macro size tests. Reading the L8 and L9 manuals the limit is 100, 200 objects which is not correct. This evening I decided to make a new Macro packing test and for my great surprise I discovered that there is no limitation in the Macro size. I could pack 600, 700 transformers, or Macro in Macro exceeding 2, 3 millions of bytes no problem.

I do not know if this update was made by chance cause Apple did not announced it and the manual info is still in-correct (it must be around L8.1 and L8.2 I guess).

Anyway you kicked me to find out that man - it is a time to create Environment tools without any limitations

Scandor, when I attempted to incorporate your 16 button macro "en masse," I indeed faced a limit. A lot of macros *precede* the place when I inserted your macro, bear in mind.

I'm still in Logic 8.0 for various reasons. But I attempted to open and use the file in Logic 9.1.1, and the same thing happened.

I'm reluctant to post this because I don't want to discuss or post pictures of the diagnostics. But I can confirm that, if too many macros (total number of objects, I'm guessing) are contained in the chain, then there is a limit as to how much information squeaks out at the end.

For example, one MIDI stream cabled to feed three instruments will only play two. If the macro is lightened or omitted from the chain, or in some cases if it is opened and made less dense (losing some functionality), the three ultimate destinations play again.

Again, I don't want to throw time at this. And your work isn't at fault. It's just that it tips the total number of objects over some kind of threshold.

I can see that you have proved otherwise, that there is no limit, and I do defer to you on these matters. But I'm the kind of person that can lose ten days to ferreting out this stuff. It's not time well spent. But it's tough to let go of your work and Ski's, because it does exactly what I wanted it to do.

By the way, I've got a lot of display macros in the chain (text boxes that reflect what is playing). Text boxes, according to the manual, take a lot of memory. I've got hundreds of these in my file. They preserve sanity when working with a lot of articulations.

Hi Plowman,

Interesting, as you both refute and confirm what's being discussed here in terms of environment object limits.

Anyway, I had a little free time on my hands today and despite the fact that I was the first to come to your rescue and that you've since kicked me to the curb, I've attached a new version. I'm using exactly the same technique I used before but incorporated a semblance of Vacheto's visual layout. There are no sysex faders, which I believe might be a culprit. Just a guess. Two transformers do all the work so this is pretty slimmed down.

Anyway, post back if it works better for you (or not).

Channel to Volume SKI v1.2.logic.zip

Aw, ski, you know in what high honor I hold you... and your eighteen dogs.... and the constant barking and the splotchy green yard....

Hmm. Here's why I don't think it's the sysex faders. I've had this before. It left inscrutably... or maybe I just stopped over-cabling. But instruments that should be triggered would just not play until I un-cabled ANOTHER instrument from the chain, like it said, "I'll play three of these, but no more."

In either case, this was long before sysex faders came into into the picture.

I'll download your file tomorrow and see if it changes things.

By the way, before a previous post, I had in fact double-clicked on the Output:sysex... of Scandor's individual boxes, assuming I'd find step-channeling from 1 to 16. But they all said channel 1. And I know I was looking at different boxes because of the title bar.

I must go to the midnight grasshopper meeting where we rub our legs like crickets and make no sound at all.

But I can confirm that, if too many macros (total number of objects, I'm guessing) are contained in the chain, then there is a limit as to how much information squeaks out at the end.

Plowman,

While I haven't looked over the environments attached here, your post did remind me that in addition to the limits on number of objects in a macro, there is also a limit to the number of cables a message can pass through. Or perhaps better stated, how many the message occupies, since it doesn't matter if it's serial or parallel cabling. I don't recall what that limit was, maybe a hundred or so. Thought I'd mention it in case that's what you were bumping your head on. Not that I'm accusing you of being a headbanger or anything.

"A lot of macros *precede* the place when I inserted your macro, bear in mind. "

"But instruments that should be triggered would just not play until I un-cabled ANOTHER instrument from the chain, like it said, "I'll play three of these, but no more."

I see. I gathered your quotes cause all that seems to be (as Fader8 poited) the cable limitation. According my tests:

A MIDI MESSAGE CAN TRAVEL THRU 397 CABLES - in the Logic Environment !

After the 398 cable that message just disappears, that's why you must un-cable ANOTHER instrument from the chain etc according your description.

As I said at first my idea to optimize the schemes was not only for the macros but and for the cable limitation as well. As I announced the Macro size limitation is fixed ( no limitation ) but the cable limit is not fixed yet.

I had in fact double-clicked on the Output:sysex... of Scandor's individual boxes, assuming I'd find step-channeling from 1 to 16.

The Sysex faders of my scheme must not be channelized as you think ( all of the Meta 123 and 122 ) are set to ch1 cause they control the transformer "UserMap" only.

Something more - my Macro uses one transformer only and do not consume so many cables ! Keep in mind that the parallel cables from the numerical faders to the transformer do not "consume" any cable resources cause your messages travel thru the transformer only. So my Macro consumes ONE cable only, but I guess you have some "beasts" which eat more...

You need to OPTIMIZE you gear following the cable limit of 397 cables.

Hint !

The cable limit can be broken down if you patch a Standard Instrument object at the and of the cable chain "Gear 1" (where you think you have exceeded the limit). Set the Instrument port to IAC bus. Cut the "Sum" cable of the "Physical Input" in "Click & Ports"

and cable your external controller Pin to "Gear 1". Cable the IAC bus Pin to "Gear 2" where you plan to use more then 397 cables.

As a whole the message(s) will travel thru 397 cables after that it will bel taken out of Logic and returned back to its input which fixes the problem.

Apart of this hint I prefer to "Optimize" the main gear inside the Logic using optimized Macros and schemes as this one I made for you.

By the way, does it work when you open my template and try it as it is ( no additional macros schemes etc ) ?

PS. About the Text faders. If you do not need all 127 name strings then you can optimize the Text fader size by reducing the top fader range from say 127 to 3 if you need that fader to show just 4 names (according my object size list each text string adds 24 bytes ). Anyway I do not believe this can be an issue...

Regards

"A MIDI MESSAGE CAN TRAVEL THRU 397 CABLES...."

This would explain why the message made it half-way through an unpacked macros (cabled to the target) when one more object cabled in the chain stopped it.

As a point of curiosity, when I reached the limit, other MIDI data would pass through, but the one critical message (the actual note to be played) stopped reporting at the pin out, as observed in a monitor. (I assume the "pin" is that nubby thing that sticks out of an object.)

"As I said at first my idea to optimize the schemes was not only for the macros but and for the cable limitation as well."

Yes, this is a valid concern and worth the streamlining. Ski's version helped me better understand the theory behind it all. The brightest bulb went off when I saw how both you and ski were using "Use Map."

"The Sysex faders of my scheme must not be channelized as you think ( all of the Meta 123 and 122 ) are set to ch1 cause they control the transformer "UserMap" only."

Right. But I still can't track how the first box knows to adjust the first Use Map line (I don't know what to call it. The 127 mapping lines that go up and down in Transformer based on the value), the second box controls the second line, etc.

I appreciate your work-around. I have a feeling you could dramatically stream-line my Environment.

For the record, I use this set-up at the Instrument layer level. Ski had noted that redundant messages would clog up the Event List. Indeed they would, but I'm using them post-Sequencer Input. So this "Ski-ndor" assembly is confined to the layer. The drawback is that I cannot set the volume to note values by remote, but no problem.

Yes, as a matter of Environmental hygiene, I've always kept the text faders ranges as tight as possible, though I did not have a reason. Now I do.

"By the way, does it work when you open my template and try it as it is ( no additional macros schemes etc )?"

Yes. And this was my solution. I unpacked the macro (you had encapsulated it after you made sixteen channels). Then I cabled directly to "Note to Vol," so all the Sysex Faders are upstream and not in the chain.

At least, that was part of the soution. In the grudging trouble-shooting I do, it's all a blur, and I just want it finished and working to get back tothe important stuff.

Why, for example, should unpacking the macro help if, as a macro, the data stream would just go through box Ch1 and then to Note to Vol? That's really only one more cable, isn't it? But I remember it as part of the solution. So I ask only out of curiosity.

All that I have lost by unpacking these macros is the aesthetic simplicity of the macro box. It's fifteen sets of boxes total (five for Violins, Cellos, and Basses). I can live with the clutter. It works.

Lest it go un-emphasized, this is a great added element in my set-up. Thanks all around.

Why, for example, should unpacking the macro help if, as a macro, the data stream would just go through box Ch1 and then to Note to Vol? That's really only one more cable, isn't it? But I remember it as part of the solution. So I ask only out of curiosity.

You are not correct here. Note, I do not use "Macro-In" and Macro-Out" labeled objects. In such cases the most "left" object is the "Macro-In" and the most right object is "Macro-Out". In my scheme the most "left" is the ornament object which is cabled to the "Note to Vol" transformer i.e the ornament object is the "Macro-In" and the "Note to Vol" is "Macro-Out".

In this sense the macro uses one cable only.

Anyway you are on your critical point of the cable limit and 10 -15 cables seems to be a problem - that's why when you unpack the Macros you save "one" cable per macro. By the way when you use unpacked macro schemes and patch to your gear then the most optimized way is to cable directly to "Note to Vol" transformer and then a cable from this transformer to the next "Note to Vol" etc. The Num boxes do not take part in the chain - keep in mind, they must stay side parallel connected to control the transformer map only.

Note, it is not bad to try to optimize your cable routings as a whole. Note, I gave an example in my scheme using "Copy Matching Events Apply Operation" transformer template. This template and the other one " .... - reverse order" are one of my favorites.

Using such transformers (when possible) instead of "Y" splitting multiple cables from one object saves cable amount resources. The other example using "Sysex" faders to send multiple messages ( they can be CC#, P-press, Fader etc ) will save lots of cable resources and objects in your schemes as well. My main idea was to focus on these two things and give some info about the scheme optimizations, object sizes, cable limit problem, which seems to be important in some situations as you found out.

I'm mortified when I go master controller shopping. I come back to my Elka and whisper, "Please don't die."

I had to chuckle when I read that. I have a Fatar Studio 2001 and a Cheetah MS5V, and I often whisper the same thing! The selection these days is truly, truly atrocious. Maybe the Doepfer, maybe. I liked the action on that Elka, btw. Anyway, back on topic...

Yes, as a matter of Environmental hygiene, I've always kept the text faders ranges as tight as possible, though I did not have a reason.

Besides the size issue, it can help for other reasons too, like if you have too many poles on a switch fader. You can start up a project only to find it's hanging on a pole that goes nowhere. Learned that one the hard way.