When performing live it is usual to move across the different sequencers (audio, MIDI). The expectation is that when going back to a previous state, everything is as it was left, but there are inconsistencies that require extra tweaking to address.
What do you want to achieve?
It would be great to switch between the modes knowing that you will find them just as you left them. For example, player could benefit tremendously if Play could remember:
Previously active sample
Last active effect on the display available for further tweaking
Previous active MIDI channel and its relevant options
Full usage examples may be found in this post’s edit history (or here).
Wow, I hadn’t gone as deep with the Play. Interesting finding!
Ok, so this wish is about remembering states when jumping from audio to MIDI and vice versa. It’s a clear and clean concept that is common in good electronic instruments and effects tools. Good!
Suggestions to improve this wish:
The title mentions jumps between Audio sequencer and MIDI sequencer but then the text also mentions jumps between sequencer mode and Perform mode. The idea is that, no matter the jumps, the user should find the same state when jumping back, right?
List the states that should be remembered clearly, i.e. in a bullet list, instead that mixed with other comments in a paragraph. This way is easier not to loose the details. If I’m reading correctly, the states you mention are:
Selected tracks
Previous active sample
Last active effect on display
Previous active MIDI channel (what do you mean with “a program for it”?)
(Maybe these points really mean “Last active step”? That should bring back whatever the user was doing last on audio or MIDI.)
Leave out little details mentioned that are not about saving state. Quoted below.
Bring back the sections from the template that were removed. Even if the initial poster doesn’t have answers, maybe other will, and they help make a stronger case. I’m adding them.
The pieces that could be removed and reported somewhere else:
If you can reproduce this, then a #bug report is welcome.
Is this still about saving states or something different? I don’t understand it.
Sorry, a lot of feedback and picking on details! You are making a clear case already but I think this will make it easier to other users and the developers to understand, support, and eventually vote.
Yeah, you got it right, and it could add like a lot to the fluent navigation. Player may want to do tons of stuff live in just a couple of sequences and in order to do it in time avoiding the repetitive actions is the must.
Yep, you’ve listed all the stuff I mentioned above in a more concise manner And when I said “a program for it”, I meant PC change (sub-option for that knob in the midi mode). All in all, it could also mean “last active step”, but for now I care the most about these exact examples for now.
I’m not sure I can for now, but will try the next time. I’ll let it be for now, because it may be in fact relevant, and I don’t have enough info for a separate bug report. Of course, you may remove it from the text, but we may forget about it then. Anyways, as you wish.
Yeah, it is about the saved states, but also about the way user could leverage it. When all the selected tracks are in the device memory, being in MIDI sequencer mode could allow player tweaking all those regular parameters with the shift button without leaving MIDI. And vice versa, as long as shift + knobs’ twisting doesn’t have a separate function anyways. Just another point for the fastest access possible with the least number of actions.
The Polyend team welcomes feature requests that are simple to understand and evaluate, by them and by the users who might vote them. @ambivalence I have edited the description to keep it to its basics. Can you check whether it is accurate, please?
The original version is here.
What is the problem?
When you try to perform live both with audio and MIDI, there is an inconsistency in the device’s behavior. For example, you can turn on the variations mode for some tracks, then switch between audio/midi and it won’t reset it, which is great, because all the stuff stays exactly in the state you left it. Still, it doesn’t remember which tracks are selected, so you cannot, let’s say, select some tracks to use in the perform mode (or with the knobs’ parameters), then switch to a MIDI to tweak something and then turn back to continue all the tweakin’ on the performance side. You have to select the tracks all over again.
Also, switching back and forth obligates user to mess with the sample knob, which is tedious. For audio you should find the previous active sample straight from the beginning while it could be just remembered and for MIDI you should select MIDI channel and a program for it.
Even though it could be irrelevant, it seems like sometimes such a reset makes other devices make infinite sounds until you tweak the channel again and reset them this way. Maybe it’s directly connected, maybe it isn’t, but it’s real pain and needs further investigation.
What do you want to achieve?
It would be great to switch between the modes knowing that you won’t lose anything. Just for another example, imagine selecting some tracks with different filter parameters. Now you tweak it and see +N (because it’s relative to their current settings). Then go all MIDI and back. Wouldn’t it be much comfy to see the same selected tracks with +N on the display, like “go on, continue your mastery”? With +N example you could also tweak it back to ~. At least, the tracks could be still selected. If there is a workflow in line with this behavior, there could be a global option.
To sum things up, here’s the list of actions that could be remembered:
Selected tracks for both audio and midi sequencers
Previous active sample
Last active effect on the display available for further tweaking
Previous active MIDI channel and its relevant options
Thanks, I made some of the crucial examples stay as they were while keeping it simple, as you wanted it to be. I guess, overly short and vague wishes aren’t that good for further voting too, because they lack real world examples of usage, so folks may not find their workflow relatable enough. It could be not clear how the suggested changes may be beneficial for all users without them, especially, taking into account that often devil is in the very details, and these details may differ a good device from the great one.
(Semi off-topic explanation about why shorter wishes are better.)
As a volunteer moderator, I got feedback from the Polyend team about the difficulty of assessing wishes that dwell too much into details, collect many features in one wish, etc. Anyway most of us don’t know about the context and constraints a development team needs to face to develop a feature…
The goal of the drafts is to be clear enough as to make it to the Wishlist for votes or not. And the wishlist is in the end a game, not a democracy to elect the next feature to be implemented. People have 10 votes each, which is more than enough to make loose choices about which wishes you want to support.
