Vangelis Technology Preview Guide

From ZynthianWiki
Jump to navigation Jump to search

1 First Steps

Here is a list of some of the changesin vangelis for the brave to try:

  • Sequence launcher integrated into mixer view - farewell zynpad, my old friend.
  • When launchers are visible, still have access to mute & solo and can still see fader level, pan/balance and meters (reduced in height).
  • Arranger disabled - not accessible but dormant, awaiting a revivial at a later date.
  • Audio clip launcher (I call him “clippy”) providing synchronised, warpable audio samples to be played in sync with sequences.
  • Bypass fore every effect - allows for true stomp-box workflow.
  • Audio mixer controls are now a processor allowing consistent access to all parameters and MIDI binding using standard MIDI learn process.
  • Visual chain management - weird tree view is gone and graphical block-based layout is here with abilty to add, remove and move processors and chains (including dragging with touch - cool man!)
  • Pinned chains - as well as the main mixbus, any other chain may be pinned to the right of the mixer view. Pinned chains are always visible and do not scroll. Other chains will scroll underneath them.
  • Additional mixbuses (send / return loops) - as well as the main mixbus, any number of extra mixbuses may be added. These act like effects returns and each additional mixbus gets a “send” control in each chain. So you can build effects chains and send signals to them with different levels.
  • Changed (more ugly???) launcher colour scheme that better matches RGB LED colours in Novation and Akai hardware controllers.
  • Better touch interface, e.g. block/icon driven new-chain chooser - this is very much a work-in-progress and may not make it into the next release.
  • Display of tempo, time signature and current beat in top bar.
  • Ability to automate playing next / previous phrase after specified quantity of bars - we call rows of launchers a phrase.
  • Ability to set the beats per bar and tempo for each phrase - with the ability to switch between 7 and 13 beats per bar, now you can perform you favourite prog rock songs!
  • Access to chain parameters directly from the chain manager view puts all the chain configuration in one place - change MIDI channel, audio or MIDI input and output routing, key range and transpose, etc. You know this makes more sense…
  • Akai APC40 integration - but other devices are probably broken - we need help from their authors.

There are many other changes under the hood and quite possibly some user facing features I have forgotten about. This is quite a change in UI and may require some documentation changes which we tend to avoid too early because updating the wiki too early is awkward and things are still changing… but we can add some tips here.

2 A brief user guide

  • In mixer view, OPT button or bold SELECT or click topbar will show the chain manager.
  • Mixbus (effects returns) have blue (bottom) legend strip. Main mixbus has dark red.
  • image
  • Cursor buttons and encoders 3 & 4 navigate the selection cursor.
  • Select or click a box to show its menu / function.
  • Bold select or bold click a processor to move it. (Also an option in its context menu.)
  • Processors can be moved up/down the chain to be in series or parallel and pre/post fader. They may be dragged with a mouse (when in move mode).
  • Bold select the top (chain) option box (grey) to move the chain.
  • Chains can be moved left/right to reorder their position. Dragging to the far right will pin the chain to the right of the mixer. (It shows in the grey background in chain manager view when pinned.)
  • Chain options (top grey box) gives operations on the whole chain.
  • Adding a processor will insert it immediately before/after the synth if selected from the synth processor menu or in parallel with the processor who’s menu is used to select insert processor.
  • A new chain is inserted to the left of the selected chain by using its option menu.
  • image
  • image
  • In mixer view, PAD button or bold SELECT or bold click top bar toggles faders / launchers.
  • image
  • The meters shrink and move to the top. The fader shrinks, rotates to be horizontal and moves to the top.
  • Audio only chains are still shown, with blank launcher buttons which do nothing.
  • Launchers on the far right are “phrase launchers” that will start or stop all the sequences in that row.
  • SELECT or click a launcher to toggle its play state.
  • Bold SELECT or bold click a launcher to edit the pattern or show the phrase launcher menu.
  • The pattern editor menu has some sequence options including naming (what appears on the launcher button), play mode (loop, play x times), etc.
  • The phrase options menu allows configuration of the phrase launcher including:
  • Duration of the phrase (how long before it performs its follow action). By default this is calculated from the longest sequence in the phrase.
  • Follow action defines what happens at the end of the phrase, e.g. trigger next phrase.
  • Tempo overrides the current tempo when the phrase starts, including if it is triggered by a follow action.
  • Beats per bar overrides the time signature when the phrase starts.
  • Phrase can be added, removed and moved.
  • The mixer processor controls appear in the control view. These include: level, balance, mute, solo, mono, phase, M+S and multitrack record arm.
  • There will also be a send page per mixbus (excluding main mixbus) with send level and pre/post fader switch.
  • Each audio processor has an additional “bypass” control that will bypass the effect when asserted.
  • All control parameters may be bound to MIDI CC using the standard MIDI learn procedure.
  • Horizontal scrolling can be done with touch by dragging the bottom legend strips. Vertical scrolling of launchers can be done with touch by dragging the phrase launchers on right hand side. This is to reduce the risk of accidental dragging on the main launchers.

Hopefully this is enough to get you going.

Something I forgot to mention is that the mixer is now split in two, with one part handling input chains and the other handling mixbuses. This allows pre and post fader effects and send / returns to be handled without the additional latency of Oram’s post-fader implementation.


3 Here are some tips for control driver authors:

  • Chains are now stored in display order - no need to call a separate helper function, just get the list of chains.
  • We have lost the concept of a list of just MIDI (launcher) chains. All chains are used and it is up to the user to move them to provide the required presentation in the hardware controller. (Maybe we could consider an enhancement here but we want it to be simple and obvious to the user.)
  • Chain id remains arbitrary and should not be used to indicate position, except chain 0 is always the main mixbus.
  • There is a “pinned” position that defines which chains are pinned to the right. Main mixbus is always pinned and always farmost right. There are Chain Manager methods to set_pinned(count), get_pinned_count() and get_pinned_pos().
  • There are 2 mixers. One for chains (state_manager.zynmixer_chan) and one for mixbuses (state_manager.zynmixer_bus).
  • Each chain may contain an audio mixer processor chain.zynmixer_proc. This is a standard zynthian processor that implements all mixer channel strip controllers as normal zctrls.
  • There is a Chain method chain.is_audio() that returns True if the chain contains an audio mixer processor.
  • The metronome zctrls are now owned by zynseq class so can be accessed without accessing the tempo gui view. You can set / get tempo, metronome enable & metronome volume from state_manager.zynseq object.
  • Mixer view has 2 modes that either shows faders or launchers. Broadly this is implemented similar to how zynpad was accessed.
  • Hardware launcher LED colours have been adjusted to allow 16 distinct colours that can be matched to APC and Launchpad colours. These are stored in zynthian_gui_config.LAUNCHER_COLOUR structure. This should be extended to provide suitable colours for other controllers, with the aspiration of conformity and consistency.
  • Although clip launcher (clippy) chains use MIDI from the sequencer for their triggers, they are not MIDI chains and have a dedicated output from zynseq. They are closer to a generator type engine (no MIDI chain, audio procesor chain) but we present them as first-class citizens, with their own engine type.
  • Clippy colours are currently simply the MIDI channel colours in reverse order. I would like to see if we could find more distinct colours, but this is a challenge. We may reconsider use of colours because the choice is limited and needs to work with various modes. This is a subject we should discuss further.
  • We have added the concept of horizontal and vertical scrolling of chains and launchers in the device controllers. (I am still working on this - the current plan is to lock it to zyngui display, i.e. top left launcher is the same in zyngui and hardware controller.)
  • Added a phrase_launcher_col which is actually the same as main column - so maybe there should be some consolidation.
  • With the simplication of ordered, contiguous chains, the code around columns has been simplified or removed.
  • zynthian_ctrldev_zynmixer has references: self.zynmixer and self.zynmixer_bus that point to the chain and mixbus mixer engines respectively. (Maybe we should use the underscore prefix convention more - I have started to do this a little, but not retro-fitted.)
  • self.mixer_col_offset probably is / should be the same as self.scroll_h. We should consolidate this, using self.scroll_h and these should probably be moved to the base class.
  • Helper functions get_mixer_param, set_mixer_param & toggle_mixer_param allow access to the mixer strip based on its position.
  • We want to abstract the sequencer code from @oscaracena’s drivers to a class, similar to how we have mixer and launcher (zynpad) classes.
  • We may also want to abstract GUI control to another class.
  • APC40 is currently the most feature rich / complete implementation of mixer, launcher and GUI control and feedback. Both @jofemodo and I have this hardware (which is a very good fit for zynthian integration) and will use it as the benchmark for driver integration. We should ensure its implementation is the gold standard and follows best practice.