Routing to Run Mode not working about performer HOT 31 CLOSED

#28

Could not let it sit on me :) refactored the routing system to be non-destructive. It was not as bad as I initially thought, although it comes with the price of some code complexity. It also adds around 2.5KB to the firmware binary and uses around 1.5KB additional memory, so it's not for free. But I think I will go with it, as it will make routing quite a bit nicer to use in general.

from performer.

It does for me. Did you forget to commit the change or select one or more target tracks?

from performer.

No, did both those things.

On further investigation, it appears Route 2 doesn't work when I route a CC from the same controller (CC 49 on Ch.0, from an Akai APC Mini plugged in to the USB socket).

Oddly, Route 1, routed to Length Bias, does work, when assigned to the first slider of the controller (CC 48 on Ch.0).

I can see on the Monitor page that both sliders work, that the Performer is receiving MIDI from both, and that the CC numbers match those that were captured by MIDI learn on the Routing 1 and 2 screens.

from performer.

Still works for me. Maybe you can attach your project file for further investigation.

from performer.

It's odd... Run Mode seems consistently not to work when routed.

Other parameters that don't seem to work (this is Routing 1, same MIDI controller, CC48 Ch.0, assigned to Tracks 1/2/3):

• First Step
• Last Step

Have send the project file to your email (don't think I can attach it here, unfortunately).

from performer.

Ah i see the problem, it currently only works on pattern 0. That's a bug. So Run Mode, First Step and Last Step are all sequence parameters. So they are unique for each pattern. Currently, it only affects pattern 0.

from performer.

Aha! When you fix the bug, will the changes made from a routed controller persist when changing patterns?

Don't know if they should or not.

from performer.

I guess not, since routed parameters should be considered more "performance" parameters, rather than "editing" parameters.

from performer.

Should the routing override, but not change the sequence parameters? I notice changing a router parameter is currently a destructive process, and it's very easy, if you're trying assigning different routing parameters, to severely fuck up your pattern, without realising its happening.

I think what I'm saying is, I think a routed MIDI CC should not destructively change a sequence parameter, but should temporarily change the parameter of the currently-playing pattern.

Whether you agree or not depends I guess on whether you view the Routings as methods of editing patterns, or performance tools for temporarily changing playback properties of the current pattern, as it plays.

from performer.

Yep, the destructive part is not very nice. But it's clearly stated in the manual I think. I might add shadow values, which retain the original setting so it can be restored if the route is removed. But this is a bit tricky too, as parameters can be routed to multiple tracks. So I would have to retain up to 8 shadow values per route for track parameters. For sequence parameters it gets even worse, at least if they can be routed to more than one sequence. It would be more like 8*16 shadow values, which gets rather large to keep in memory unfortunately. That's the reason I'm still not 100% sure if routes for sequence parameters is a good idea to begin with (although it's very fun to use).

from performer.

Routings are primarily intended for performance, so it's about setting up a few routes that one wants to use for performance. Then, the destructive nature of them is not too much of an issue in my opinion.

from performer.

Our messages crossed...

I see what you mean about "shadow values". Would it make any sense to think of it the other way round? ie the "shadow values" are the actual values stored in the pattern, and routed values override selected values in the currently-playing pattern(s).

That way, they're more like a "note FX" applied on top of whatever is playing.

You don't have to restore the original values, because they're not changed, and you only have to store values for the routed parameters.

from performer.

It conceptually separates "editing" (destructive) changes from "performance" (non-destructive) ones, which I think is a useful distinction. Plus, it reduces the likelihood of accidentally screwing up your patterns without realising it (which is quite high, currently).

from performer.

The shadow values are what the current implementation would require as routings effectively change the origin values. The current design is not perfect, changing it is non-trivial however. I will consider a refactor though, as it clearly has limitations.

from performer.

I guessed it might require you to write new code for routings, where you may have been able to hook into the editing methods, with the current setup.

from performer.

The current implementation is way more straight forward. And it works well enough I think, but it has limitations.

from performer.

Don't get me wrong- it works really well ('pattern 0' bug notwithstanding), it's just I think it's slightly confusing, from a usability POV, and I think it will catch a lot of people out.

from performer.

Incidentally (and sorry to derail the thread), but are you still up for adding APC Mini support. Now mine has arrived, I'm happy to post it on to you so you can test it, if it would be helpful.

from performer.

From the manual:

Note: When creating a route, the original value the target parameter was set to before creating the route is lost. This also implies that the target parameter will not go back to its original value when a route is deleted.

from performer.

Yep, it's good you point it out in the docs, just would be better (in my opinion) if it didn't work that way.

from performer.

Sure, I was never fully happy with it from a design standpoint either. It's still super functional though. Sometimes there are tradeoffs to be made ...

from performer.

It's still super functional though.

Absolutely!

Sometimes there are tradeoffs to be made ...

Of course. And you've already squeezed an awful lot into this module, and it's a Lot of fun to use.

from performer.

Of course. And you've already squeezed an awful lot into this module, and it's a Lot of fun to use.

Yep, sometimes I wish I didn't go as far :) also now that other people start using it, areas that I didn't put much focus on myself might exactly be what other people are looking for. That will definitely improve the functionality and polish of the product. But it also means there will be a whole lot of feature requests and ideas coming up. I will try to work on the stuff that seems most requested, but it will definitely be impossible to follow every single request.

from performer.

it will definitely be impossible to follow every single request.

That's for sure...
I've been lucky in the sense that I've got my requests in early ;)

from performer.

Hmm.. I think I may have found another bug, related to routing.

I had previously had a CC routed to gate Length Bias. I removed the routing, but now it seems like the last value I set from the controller has got "stuck".

I can no longer change gate length of the output notes, even though the length appears to change, both on the LP Mini (which I've now re-plugged), and on the Performer display.

from performer.

I can no longer change gate length of the output notes, even though the length appears to change, both on the LP Mini (which I've now re-plugged), and on the Performer display.

The gate length bias parameter on the track settings might still be stuck at the last value. Just move it to 0. That should work hopefully.

from performer.

Gaa, it's that destructive thing again... That was it!

from performer.

But it also means there will be a whole lot of feature requests and ideas coming up

Also means you can't change stuff so easily, as people will potentially complain if you make major changes to functionality.

from performer.

Also means you can't change stuff so easily, as people will potentially complain if you make major changes to functionality.

As long as this is not a commercial product I don't really care to be honest. People can always decide to keep running a specific version (or fork and backport) if they mind the changes. I don't want to inhibit development at this point yet just to be backwards compatible and keep things in place. This will change of course when there is a commercial version, as I will piss off my customers :) That being said, of course I will try to keep things consistent as much as possible.

from performer.

Fair enough. Us early-adopters have no reason for complaint, given we're getting a sneak-preview of what's going to be an amazing product, plus the chance to dissect the firmware and hardware and learn from it.

it's definitely to your credit that you chose to release your work into the public domain at this stage, no matter what your eventual plans are for it.

from performer.

You, Sir are a Star! :)

Can’t wait to test it. Shame I’m away all next week, so won’t have much time to play with it.

Great work!!

from performer.