Great to hear that
I don’t know of any device. Care to elaborate?
In hardware world this is basically best practice since the inception of midi (and even before in other protocols), so I really wonder what those “many” devices are
A lot of vintage MIDI devices like early step sequencers use the MIDI clock as the transport progress and only used START, STOP and CONTINUE to define the pause / stop (and rewind) operation when clocked from external MIDI. (STOP is effectively ignored if not using its internal clock.) This would have been to minimise the limited CPU usage, i.e. the sequencer advances directly by MIDI clock pulses.
This approach is still used by some (many) devices - but I am keen to hear from @everyone about their MIDI connected hardware and whether it expects continual MIDI clock or for the clock to pause when transport is paused/stopped. I do not own a lot of time-based MIDI devices so let’s hear from the collective.
1 Like
I must say that the direction this is heading to with zynbleton is wonderful! Just updated without any issues.
The first things which came to my mind was:
- The path to add a new chain got a bit longer. If I don’t overlook something, it is “opt” → navigating to main bus options with two encoders → navigating to “add new chain”. Before it was just “opt”-“enc4”. An option would be maybe to have a small [+] button next to the chains?
- I would like to know if the transport buttons could have some use inside the new zymbleton mixer view. I think the record button triggers “global” audio/MIDI recording unrelated to zynbleton, am I right? It could be related to record a focused “pad/clippy/pattern/
*”. Also play/paus/stop buttons could be related to the zynbleton “sequence/*” or the focused pad. - Looking forward to some docs about the “global transport” in metronome view, because I cant figure out what it is for. I just somehow managed to get two seperate click beats running.
* = Don’t know how we call this concept in zynbleton now.
2 Likes
+1
Would love to totally disable the global record/playback for my use
Think that recording a session is something useful. I use to do it frequently.
I can’t figure a better use for the transport buttons in the launcher’s view, but we are open to workflow improvements, so make a detailed proposals, please 
Kind Regards,
The problem about no sounds from intruments is solved after the last update 
1 Like
I like this;
Bu ti really use the global recordplayback quite a lot;
Are you also using global MIDI recording a lot? We could figure either:
- Use record and alt-record for clippy record/global record or
- use global record from the mixer view and clippy record from the zynbleton view.
I understand that global record is important for many of you, the question is maybe if it needs to be accessed directly from everywhere (which in the above proposal still is)
No never, actually
It would for my part certainly be nice to have it available most places, and definately from Launcher
Yes, absolutely. Both audio and MIDI.
Hey hey. This would be very very useful.
I updated to Vangelis just today so I probably still need some time to try and discover all the functions and options. But If I understand it properly - I have to open clip editor view to record midi notes and I can not record midi into clips when I am in zynbleton/launcher view? I am used to ableton clips - I press a clip and it starts to record. 
I think the @hannesmenzel suggestion is close to this.
1 Like
Chain UI suggestions:
- no need to specify “options” after every chain name, thats self explanatory and just clutters the UI
- The add processor UI with plus sign in blank MIDI chain could use some design, the block is unnecessarily high. Perhaps instead of solid color it should have no color and dashed border, less height
- adding a chain could indeed be more straightforward, I currently have 10+ midi chains so there was lots of scrolling to an unintuitive location.
- was there a duplicate chain option? Cant remember but seems useful
1 Like
Thanks for the feedback - all really useful.
You don’t need to insert new chains at the end, using the main mixbus menu. They may be inserted at any position using the adjacent chain’s mixbus menu. This is an improvement over the old system, where chains were always positioned at the end. But you are both right that there may be more scrolling if you always want to insert a chain at the end. Adding a [+] at the end does not resolve this - you would still need to scroll to it. I wonder whether we can turn our heads upside down and consider this in the opposite to convention? Imagine that you add a chain, configure it and are happy with it then want to add a new chain. One might consider that the new chain that you want to add, configure, etc. may benefit from being the first chain - so the ability to insert it there quickly makes some sense. Ot consider the concept of adding multiple chains in quick succession. You may want to add the new chain adjacent to the previous one which should mean that the cursor is already where you want it (or adjacent) because it is on the chain you last added. Also, moving chain position is fairly simple. Let’s consider these workflows and mindsets before considering alternative implementations.
“Options” is redundant - I wanted to indicate this was the chain options rather than a processor block. Colour helps but should not be the primary indication. It may be acceptable that documention will suffice to indicate that the top (grey) block is the chain option whilst others are processor blocks (or inputs/outputs). I will remove the word “Options” and we can see if that is okay.
The block sizes are all designed to be finger-friendly so they work well with touch, hence the [+] block to add a processor is the same height as a normal processor. It only exists if there is no other way to add a processor so it does not unnecessarily increase the max/min height of a chain. Initially it was grey but I felt it made sense and presented less clutter to be consistent with the MIDI processor colour. I want it to be clear that MIDI signal flows through this (non-existent) dummy block and chaning colour may give the wrong impression. I worry that [+] is insufficently vague, but no one has yet suggested it is not understood. Remember that once a chain has been added, the [+] disappears.
There has never been a duplicate chain option. Sounds like a feature request.
The discussion on how to use transport buttons is probably worth deferring. We do not have an audio clip (clippy) record workflow and it is not imminent. We do not have a global transport (I am removing the PoC that I added in the last update) or Arranger. We do have global audio and MIDI recorder and player so it makes sense at this time to retain the transport control for those (working) modules. I am not sure that transport control works well with clips from a global (launcher / zynpad) view.
2 Likes
Change perhaps to “Add processor” for now?.. icons can always be added later, but the + is not an icon, it’s text hence it looks a bit off.
I still think the best way to indicate it as an action rather than a filled processor is to make a slight visual difference.
This can be for example dont fill the rectangle and just draw a border (not filled yet/can be filled)
Personally I feel this pattern can be useful to repeat in other places, such as to add fx (at any time), chains etc.
I also think height could be slightly adjusted while keeping it touch friendly.
But this really requires perhaps someone with graphic/UI design background to comment
1 Like
For V5, we have 4 knob clicks available and currently only knob4 is used. The other 3 could be asigned to useful shortcits, like add chain, add procesor, etc.
Regards
For backwards compatibility such operations, might perhaps, best be left for equivalence with V4 and before?
1 Like
I just switched the font to Helvetica, as that’s what I was using before (it’s easier on my eyes).
The text on the chain manager screen is rather small, and increasing font size in the web UI only changes the title. So I reverted back to audiowide for now
100 Posts in, and we are setting fonts.
High praise for a dynamic new GUI component.
This upgrade must be regarded as a success!
Time to heap praise on those least non-contributory.
Well handled!
Much to celebrate!
2 Likes
About SooperLooper with regards to Clippy.
First about the alternative point 1 (using SooperLooper .wav files). I thought about this a while ago in another context: downloading SooperLooper sessions from webconf (not possible now except in the context of backup) and loading loops of one SooperLooper session in another.
Having the wav files available in places where ‘captures’ are normally available would ease this. And also loading it in Clippy.
If this would be in the captures folder itself, the slsess files also need to be there (which count as ‘presets’ from a Zynthian UI perspective.
Note that if we are to revise the storage of SooperLooper we might want to introduce subdirectories, so that downloading a session with audio as a preset would be easier to implement.
Then about using SooperLooper as a utility from another program (clippy) to record samples, this feels a bit like a kludge. E.g. to end the recording, a process would still need to track time. Even with multiply - this is picky on when the extra commands for number of cycles are given. If using SooperLooper programmatically from clippy, I think this would need a separate instance, leaving real SooperLooper usage to the whims of the user.
I did some tests, recording in SL synced to Jack works. Quantization to cycle. But just kinda. In my test, it started recording on the fourth beat in a 4/4 bar. Or the metronome isn’t right. Then when you have recorded a loop, change the tempo of Zynthian, change it back, SooperLooper can suddenly play sync to e.g. the third beat. Can also be I don’t understand all intricacies of MIDI clock, Jack transport and such.
1 Like
I have similar experience!