Ok, I'm getting myself in a mess now!

Build 3668 up now has this.

Brad, you’re a genius!

Thanks.

I did think about getting caught in a loop of these, I think I should be ok though, like I said in a post above, I need Inception bindings…

Cheers.

P

1 Like

Hi Brad… You’re going to hate me!

The change you made doesn’t work for me. I’ve tried both ‘Refire State on Load’ and ‘Refire Rack on Load’ and neither of them send anything… (At least not to where I need it…)

Just to make sure I’m using them correctly, here’s how I’ve got them set:

I’ve tried different combinations, using one binding and changing the target and using 4 like shown here and enabling/disabling them as the states change. I’ve got the bindings in the top level of the rack, I thought that maybe I should have them in the embedded racks, like this:

That doesn’t work either.

Just to reiterate, in case I hadn’t mentioned this already, if I toggle the running suspended state of the top level embedded racks (Piano, Rhodes, Clav, Organ) by clicking on the green light in the rack, this does exactly what I need, which is what the previous bindings were achieving, by turning them on or off dependant on state.

Sorry…

P

Hi @brad,

Any thoughts on the above, I can’t seem to get it working? It’s probably something I’m doing wrong…

P

Hi Pierce,

Thinking on this and may have a suggestion that could work. In the architecture of your overall plan the light assignments for the embedded rack states where each patch or state you call up changes the secondary panel lights on the controller switches. You currently have the light assignments for each sub rack in the sub racks’ states. What if instead you had all the possible secondary panel light combinations for all your patches on all your keyboards in their own rack that sat on the same level as your main large Pad lights rack. You could add to it if needed and since many secondary panel light combinations would be the same you could reuse the states you built in it for multiple patches. The way it could work then would be that each patch on the bottom level could send a CC message to the top to call a state in that secondary panel light rack I talked about creating. I think it would trigger the light changes every lowest level state (patch) change that way. Does this make any sense?

Main board Rack using the Clav rack as an example for the connections and re configuring & opened to first level for edit, notice the added panel switch light rack

and the new bindings added at this level to receive the CC massages from the Clav rack patches below

This would be the Clav rack opened for edit view with pared down look on routes

and the bindings in the same Clav rack that send the CC messages up to the New light rack I added for each patch change.

Cheers,

Dave

Hi @dave_dore

Firstly, can I thank you for all the time and brain matter you’re expending on my silly little problem, it really is truly appreciated!

I did think long and hard as to where to put the racks for the switch lights and came up with the scheme I did because that was logical for me. The scheme that you came up with is pretty elegant, but I see 2 issues. The first is the sheer number of states in the ‘Panel Switch Lights’ rack I’d need to make this work. In the main board rack, that we’ve been looking at, it wouldn’t be that many but in the upper board rack where I’ve got 8 categories, many with 7 or 8 different sounds, some of which are exclusive, some of which are switchable, would make my brain hurt…
Secondly, I’m not sure that this way round would solve my issue with the lights not resetting on ‘Category’ changes. The bindings at the moment don’t re-fire when the state changes from Piano to Rhodes etc to change the lights and despite @brad magnificent effort to help me with adding new bindings targets, I still can’t get this to work…

The racks as I’ve got them work exactly as intended, in and of themselves. The one thing I need to be able to sort out is the ‘Cycling’ of ‘power’ to the category racks when they’re selected. which, if I do it manually, resends the bindings in the state they were left from the racks (Clav Rack, Piano Rack etc)

If I’ve misunderstood how your scheme works @dave_dore please let me know.

When I’ve got some time this week, I’ll have a go with your idea, see if it makes a difference.

Once again, thanks for the amazing amount of effort you’re putting in to help, Dave, it’s truly appreciated.

Cheers,

P

I wasn’t aware how many variations there were so I understand the problem there.

You are right, it might just do the same thing but I can’t truly test such a thing here and am going on theory & testing the various functions to see what they actually do. If possible can you put all the rack files you use in your main keys linked rack in a zip file in it’s latest form and post it here. The complexity would be shown to me then much better.

Cheers,

Dave

Of course. I include the rack, with my old solution of turning the racks on and off with state changes in order to reset the lights.

You’ll see what I mean about the large list of possible states I’d need if I moved the channel lights rack up a level to the ‘root’ of this main board rack…

Main Board Aug 20.zip (5.1 MB)

Once again, many thanks for your continued help (I know I’m sounding like a broken record, but I really mean it.)

P

I’ll take a look Pierce :slight_smile:

Dave

You’re a gent Dave!

Like I said though, I’ve got it all working exactly how I wanted, bar the fact that I can’t have the sound continue when I change racks, due to the fact I have to turn the racks off when I change category. This is what @brad was helping with when he wrote the new binding in but (no doubt because I’m doing something wrong…) it didn’t work for me.

Cheers.

P

Hi Pierce,

I think I may have figured it out. I disabled your bindings group that you set up to ensure that the bindings fired for the switch panel lights by enabling and disabling the racks. I replaced it with a single binding that still uses the target behavior so for each state it sends a CC0 momentary message to the rack (Clav, Piano, Rhodes, Organ) that is selected. The Clav example is shown here

Then inside each rack I put this group of bindings that received the CC0 message and re-fired the light rack bindings.

I don’t have your keyboard but I checked it ob a MIDI monitor it has the same sys-ex message outputs as your current rack configuration but now you can have all the category racks enabled and not have a sound drop on changes between them.

I don’t know how it will transfer but I will post the rack with edits made here so you can have it to look at or use (if it works out of the box) either way for me it proves that Brads’ new bindings do fire correctly. Like all things I may have missed the point all together but I do think this will help.

Main Board Aug 20.zip (5.2 MB)

Dave

Dave, you’re a genius!

That works perfectly! I still don’t understand however why it needs to be a 2 stage operation, why I need to fire the CC0 to the rack to get the lights to refire, rather than having the Main Board rack just tell the Piano Rack (or whatever) to re-fire it’s bindings.

But, I’m not going to complain, it works and I’m really grateful for your amazing help!

I wish I was down the road so I could buy you a drink!

Cheers,

P

2 Likes

As best I can explain and purely based on using the new binding target the logic requirements for it needed to met and the embedding you used needed a more targeted trigger method. That’s my best try at it :grin:

@brad can explain it better from the technical view I think now that the issue has been resolved as far as when you have the re-fire option appear as a possible target and what possible Source events can trigger it properly. In this case we went with a straight ahead CC edge switch binding.

So I’m glad we whipped it, it really makes your keyboard work elegantly when used live to have indicators that move with the patches.

Dave

1 Like

Yes, it’s quite satisfying now, maybe I’ll take a video to show you…

Now I’ve got to work out how to do it with my MPK261 (I’ve got @terrybritton rack for the lights, so hopefully I’ll be able to work that out!)

Saying that, thanks to your help, I’ve got the Cantabile side of it all worked out, so it should!!! be easier…

Cheers

P

1 Like

Ok @dave_dore, I’ve got one more odd issue…

Remember how I said that one of the racks was receiving note offs even though it’s MIDI route was switched off? Well this is now causing me an issue. I’ve made it so the channel lights now send notes on channel 4 and the bindings for the state changes fire on note offs:

The problem is, and it was mentioned in the other thread Dave, is that for some reason, the Clav rack is receiving these note offs even when it’s MIDI route is switched off. This means that it’s causing issues with the lights because the bindings in the Clav rack are being fired as well as the ones in whichever rack is selected. I’ve done it like this because the Keylab has an annoying trait in that if you hold the button for slightly too long, it defaults to the light state that you set in it’s software. Therefore set it on note off (as I release the button) it’ll fire after the button press and all is good…

These pics are with the Rhodes rack selected and as you can see, the Clav Rack is the only one still receiving these note offs (other than the rack that’s supposed to be…):

I know we kind of glossed over this one in the past, Dave but it’s an issue now. @brad, can you think of any reason for this?

Cheers,

P

For what it’s worth, the Clav rack also receives the note offs from the keyboard on MIDI channel 1…

P

Hi Dave,

So, the plot thickens…

Upon loading (or resetting the Audio engine, which reloads the song back to default state), if I switch backwards and forwards through the patches, all works great, no racks receiving anything they shouldn’t…

However, when I open one of the embedded racks, it starts behaving weirdly. Oddly though, it’s not necessarily the opened rack that then starts receiving the extraneous note offs…

:exploding_head:

P

Ok, scratch that…

Trying to do more investigation has stopped it happening…

I’ve changed nothing in the racks, nothing in the routing. Now I can’t get anything to receive the note offs… (note offs they shouldn’t be receiving…)

This is weird.

P

Hi Pierce,

I looked at the pictures you posted the other day and the bindings have been changed from PG chg to note off sources in your sub racks. For me to help I would need to see what you have modified and are using now so post the updated rack when you can.

Cheers,

Dave

Ok, again scratch that, it seems to be random, I was editing something in one of the racks, now the piano rack is receiving extraneous note offs…

Anyhow, as always thanks for your offer of help Dave, here’s the new version of the rack…

Main Board Aug 20 experiment.zip (827.4 KB)

The only thing I’ve changed from the one you’ve already seen Dave is that I’ve changed the buttons to output notes instead of program changes.

Cheers,

P