I added this new step to the workflow:
I’m thinking the best way of implementing MULTI edit for the rest of parameters.
Regards,
I think you did that many wonderful changes the last couple of days that it might one day be necesarry to make a step back to check if the entire implementation keeps some kind of straighforwardness.
I’m not at home right now, but I would like to review some kind of tree view which of the encoders are used right now for what on each of the levels.
But some kind of entering a selection mode while keeping the basic input methods would be great (somehow entering multi deit mode, select region, then select and change values with encoder 3 and 4 and quit. Or: having a selection always on (default 1 step)
A little demo on MULTI edit parameters:
Regards!
5 Likes
Looks very promising! Does it edit the common parameters absolutely or relatively? (I mean, what happens if you edit multiple steps which had different parameters before)
realatively
1 Like
Away from Z, but i guess that if you want the multiple steps to go from multiform to uniform, you can dial them all to 0 or 127 and then adjust them from there?
Exactly. But relative adjustment has only sense when the parameter is numeric. It hasn’t much sense for stutter ramp, for instance, that has 3 values: NONE, UP and DOWN. In these kind of parameters, the adjustment should be absolute, but then, what is the initial value? I’m thinking about all this …
Regards,
I understand, maybe they could inherit the value from the leftmost step at the first movement of the knob, and then you can dial it in
But it could follow the same logic. Multi edit increments/decrements either value. You can push every of them to the limit, then turn them back altogether. This is also true for 3 int values and even boolean.
And you keep the relative edit possibilities.
Editing all values to a common one might seem more elegant, but would omit the possibility for relative editing (i.e. make all 32 hihat hits a little louder without changing the dynamics).
Also I think it is really difficult to have a general method deciding which int/enum parameters are fine to edit relatively (stutter count) or absolutely (stutter ramp).
Sounds good
This also sounds reasonable, but I would prefer that as an alternative (ALT-mode) control.
I think at this point there may be some considerations about visual feedback:
- Some visual representation on the UI what encoder movements and different pushes do in an ever increasing complexity of the UI.
- Specifically for multi edit: when editing a single step, then the parameter value is displayed in the top bar. There might be some visual feedback there that there are multiple, different values edited at the moment, but when you reach a limit (min/max of the parameter), or you are editing them in some kind of “absolute” mode, it may feedback that value in the top bar as well?
1 Like
I just updated to test things
The pianoroll focus and highlight changes are perfect, really improves the usability a lot.
However, something weird is going on, every midi note is doubled. So when I play on external keyboard, I get 2x Note On on the DIN midi output. When I program a step, 2x Note On, When I launch a clip, 2x Note On, etc..
I’ll troubleshoot some more to see if there’s a setting is to blame (worked fine before on this snapshot)
EDIT: Does not seem to happen when starting from scratch.. investigating further.
EDIT2: The UI freezes when pressing encoder #1 twice while in piano roll. The only way to unfreeze is to go to the web config UI and save the UI options there (causing a soft reboot)
EDIT3: Wasn’t able to reproduce the double midi notes. Guess I just needed a proper reboot after the update!
You are right. It’s fixed now.
Thanks!
1 Like
It does.. but it still has a “bug”:
when “record” is active, it will focus on the note received, however it will immediately focus again on wherever the cursor was
this is not really useful, and causes flashing.
Understand! I hope it’s fixed now 
Regards
Not yet?
zyncoder: vangelis (2e0799e)
zynthian-ui: vangelis (fb7b8be)
zynthian-sys: vangelis (4d67d5d)
zynthian-data: vangelis (781d76c)
zynthian-webconf: vangelis (fc913b2)
Sorry, my last push didn’t work. Try now!
Regards
Needs a high speed guitar solo over the top 
Hi everyone, 
I am delving into the new Zynseq Implementation in Vangelis, and its possibilities for my musical workflow.
With the Arranger screen temporarily omitted, I am not finding a way to play integrally from the sequencer view a whole set of patterns in all chains (say, a song) with their assigned repetitions, without launching them manually from the on-screen pad matrix (or from an external pad surface controller, which I don’t have or use).
Is this somehow already implemented? I did not trace this function either in the Oram-based existing documentation or in the forum, but maybe it’s just me not looking in the right places, or simply lacking more expertise of this specific Zynth application. Maybe the answer is quite straightforward.
A suggestion: would it be possible @jofemodo to reunite even essentially, somewhere in the forum, all the existing bits of information on the new and currently tested encoders and buttons actions, in the sequencer and pattern screens?
Cheers!
1 Like
The launcher view now has a “phrase launcher” in the last (main chain) column. This triggers the sequences in that phrase (row). If a sequence is disabled then it is not launched and the currently playing (mutex) sequence control to play. You can automate the progression of the phrase launchers, e.g. play 4 times then play next phrase. This is fine in the phrase launcher menu, accessed the same was as you would access the pattern editor from a normal sequence launcher. This allows for songs to be sequenced.
2 Likes