Grouped / collapsible mixer channels for portable live-set workflows

Software
1

Hello,

This is a feature request for grouped or collapsible mixer channels in Zynthian, mainly from the perspective of a compact live‑performance setup.

Hardware setup (for context)

My rig is a lightweight, portable Zynthian setup built around:

  • A Raspberry Pi–based Zynthian box with a small touch screen

  • A powered USB hub

  • Akai APC Key25 Pro (pads and rotary knobs)

  • Korg nanoPAD and Korg nanoKEY (for triggering and extra keys)

  • Akai MIDI Mix (for mixer‑style faders and knobs)

The idea is to have a minimal, easy‑to‑transport live‑set rig: one Zynthian box plus a few small controllers, instead of a large external mixer and heavy hardware.

Use case

The workflow involves ZynSeq plus these compact controllers for playing, triggering, and mixing different musical parts during a live set. This is not really genre‑specific. I personally use it for tekno‑style workflows, but the same issue would apply to anyone building live sets with multiple drum, synth, bass, sample, or FX chains.

Current problem

When a setup grows beyond a few simple parts, the mixer can become crowded, especially on a compact device and screen. This is most noticeable in live sets, where clear overview and quick control matter more than in slower studio editing. For example, a user may want separate chains for kick, snare, hats, bass, synths, sample loops, and effects, while still treating some of those as one musical group during performance.

Current workarounds

There are already some workable approaches, but each has trade‑offs.

1. Put many drum sounds into one mapped drum kit chain

Using a mapped drum kit can be very convenient because the sequencer can show labeled drum names instead of forcing the user to remember note assignments. This is good for fast beat programming and keeping one kit on one mixer channel.

Pros

  • Cleaner sequencer workflow because drum sounds are labeled.

  • Fewer visible mixer channels.

  • Simpler live mixing because the whole kit can sit on one fader.

Cons

  • Audio effects added to that chain apply to the whole kit, not just one part.

  • This makes it less flexible when only one element, such as the kick or bass‑heavy part, should get distortion, modulation, or other dedicated processing.

2. Split drum parts or samples across multiple chains

Another workaround is to place important parts on separate chains, for example kick on one chain, hats on another, loops on another, etc.

Pros

  • Much better control over per‑part effects and routing.

  • Better sound‑design flexibility for live shaping.

Cons

  • The mixer becomes more crowded.

  • It is harder to keep a quick visual overview during performance.

  • It creates tension between flexibility and usability in a portable setup.

3. Use scenes and external pad triggering as an organizational workaround

Another helpful workaround is to keep main musical parts in one scene and extra loops or sample patterns in another, then trigger those from an external pad controller instead of constantly changing what is shown on screen.

Pros

  • Gives more performance options without overloading one visible grid or page.

  • Works well with compact external controllers in a live setup.

Cons

  • It helps with organization, but it does not solve mixer clutter directly.

  • It does not create true visual or functional grouping inside the mixer itself.

Why grouped / collapsible channels would help

For this kind of compact live rig, grouped or collapsible channels would be a much better long‑term solution.

For example:

  • A “Drums” group could contain kick, snare, hats, toms, percussion, or loop chains.

  • A “Samples” group could contain sample players or trigger‑based audio parts.

  • A “Synths” group could contain bass, leads, and atmospheres.

Each chain could still keep its own routing and effects, but the user could collapse the group for a cleaner overview during performance. This would preserve flexibility while making the mixer far easier to use on a small portable system.

Ideally, this could also support some kind of group‑level control, such as a group volume or maybe optional group processing, while still allowing detailed editing when expanded. That would be especially useful for people using Zynthian as the center of a lightweight live‑set rig instead of relying on a large external desk.

Why this matters

The current workarounds are usable, and they already help in real workflows. But they all involve compromise:

  • One chain per kit improves labeling and simplicity, but reduces per‑part FX flexibility.

  • Multiple chains improve sound control, but reduce mixer clarity.

  • Scene‑based workarounds help performance flow, but do not address mixer grouping itself.

Grouped / collapsible mixer channels would solve the core issue more directly. For portable live sets, this would make Zynthian easier to perform with, easier to scale, and easier to keep visually manageable without losing routing flexibility.

Related secondary topic: APC knob mapping

A related but secondary topic is MIDI controller mapping. In my setup I use an Akai APC Key25 Pro. The pads already work well for triggering and launching patterns, so this is not about changing pad behavior. The request here is specifically about the rotary knobs on such controllers and what they can be mapped to.

As a secondary consideration, it would be useful if the rotary knobs on controllers like the APC Key25 Pro could be mapped not only to individual chain levels, but also to sequence‑ or group‑level controls in ZynSeq and the mixer—for example, controlling the overall level or presence of a given sequence or group of sequences during a live set. This feels easier to design once there is a clear concept of grouped or collapsible mixer channels, so it may be a separate request.

If this sequence/group‑level MIDI mapping for knobs is better treated separately, would you prefer that I open another feature request here on the forum or a GitHub issue specifically for that topic?

Thanks for considering this.

2

I wonder if the following Vangelis features could get you closer to what you want:

  • 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.

(From a post by @riban)

1 Like
3

Indeed! Vangelis has mixbuses but even with Oram you can create a group chain by adding an audio chain and routing other chains to it.

4

Thanks, this already sounds very promising.

I’m currently running Oram 2601.1, but I’ve now found a spare SD card, so I’m planning to download the Vangelis 2606 test image and try these features directly on a separate card. That way I can keep my Oram setup intact, but still experiment with pinned chains and the extra mixbuses in Vangelis. Once I’ve done some tests with my portable live‑set rig, I’ll report back how far that gets me toward the workflow I described.

Pinned chains sound great for my setup: I could keep a “Drums” chain, a “Samples/Loops” chain and maybe a main “Synths” or “Master” chain pinned and always visible, while other chains scroll underneath. Additional mixbuses also sound useful for building shared FX returns or group processing—for example, sending several drum chains to a common drum FX bus or having a parallel distortion bus.

My request is mainly about visual/structural grouping on top of whatever the new mixer already provides—being able to fold several related chains under a group or folder, so the mixer view stays clearer on a small screen during live sets. Pinned chains, extra mixbuses, and group chains are a big step toward the “one fader per musical group” feeling; collapsible groups would be the next layer that reduces clutter when many chains are involved.

One practical question: is there any rough idea about when a stable Vangelis release might be expected? I’d like to know when there will be a stable version that I can really invest time into for live playing, without having to worry too much about system errors or breaking changes when I’m trying to perform. My plan is to keep my current work in Oram snapshots, back them up, and then try loading those snapshots in Vangelis when I test it, since Oram snapshots are supposed to be compatible in that direction.

1 Like
5

Vangelis is in the latter stages of testing, with an effective (but flexible) feature freeze and concentration on bug fixes and documentation but we don’t work to a rigid or strict timeline. We aspire to getting a new stable release out in the few months but don’t base any plans on that.

What you can do is to use Vangelis and don’t update if you have a platform that works for your workflow. There is no automatic update so you are in control of the version. If you find that Vangelis is sufficient for your current workflow, you could use it on one card whilst keeping the other for testing updates to see whether they break anything. If you take this approach I would recommend that you write some test cases so that you can prove all your required workflows continue to work.

A risk with working on Vangelis is that we have not finalised the state model so there could be some breaking changes that won’t have a Vangelis-to-Vangelis fix. We aim to ensure Oram snapshots migrate to Vangelis. This risk is fairly low now that we are near deliver and have be a lot of users on Vangelis.

3 Likes
6

Thanks for the detailed explanation, that helps a lot, and I just want to say I’m very happy with Zynthian so far and really appreciate that it’s being actively developed. It already does a lot of what I want, and it’s great to see the mixer and workflow evolving further.

Knowing that Vangelis is in late testing with a feature freeze and a focus on bug fixes and documentation, and that there’s no automatic update, makes me more comfortable trying it for my workflow. My plan is to:

  • Keep my current Oram 2601.1 card as a stable fallback for playing.

  • Use the spare card for Vangelis, starting with the 2606 test image.

  • Write a few simple test cases for my main live‑set workflows (drums + samples, scenes, APC/nanoPAD controls, mixer use), so after any update I can quickly check that everything still behaves as expected.

It’s reassuring to hear that Oram snapshots are expected to migrate to Vangelis and that the risk of breaking changes is fairly low at this point. I’ll back up my Oram snapshots and then try loading them in Vangelis when I start testing.

For now I’ll treat Vangelis as “stable enough to explore” while still keeping Oram around for performances, and I’ll report back in this thread once I’ve tried pinned chains, extra mixbuses, the group‑chain approach, and how all of that feels in my portable live‑set rig.

Also. If its interesting for anyone, i can always post photos of my setup.

2 Likes
7

I’d be interested in photos and-or videos of your rig with Zynthian in use!

8

I’ll make some fresh shots asap for you

9

Quick update after spending time with the new Vangelis build alongside my existing Oram setup, using both in the context of a light weight live performance rig. These are only my initial findings after playing around with it this afternoon.

What I like in Vangelis

There are things in Vangelis that clearly move in a direction I appreciate:

  • The UI feels more modern, and some tools and views are easier to reach.

  • The clip/scene‑style sequencer ideas fit well with how I think about building and launching patterns in a live set.

  • It feels more natural to route different sounds through a single output or bus, for example treating “Percussion” as a shared output for multiple engines, which is exactly the direction I want for grouped drums.

So I don’t see Vangelis as “wrong” — it’s clearly aiming at a more DAW‑like, Zynbleton‑style workflow that matches my general mindset.

Why I still prefer Oram for actual performance

When I actually use both builds for my live rig, Oram still fits my workflow better, mostly because of the interaction between sequencer, mixer, and controllers:

  • In Oram, I can have multiple sequences running through channel 1, activated by a single pad or single column of pads on the APC Key 25.

    • That effectively gives me a compact “rhythm group channel” in my head: one column of pads drives a set of related patterns on one channel, and I treat that channel as my drum lane.

  • The mixer is simpler and, with my existing habits, feels less overwhelming than Vangelis when I start juggling drums, bass, FX, atmospheres, etc.

So even though Oram isn’t perfect, the combination of pad/sequence behaviour and mixer layout currently makes it easier for me to keep the live set under control.

What’s difficult in Vangelis right now (for my use case)

On the Vangelis build, I’m hitting several practical issues:

  1. Actually more mixer crowding and lack of grouping

  • With separate chains for drums, bass, multiple synths, FX and atmospheres, the Vangelis mixer fills up extremely quickly.

  • I don’t yet have a clear way to group or collapse channels into live‑friendly bundles (for example, “Drums”, “Bass”, “FX”, “Atmos” groups), even though that kind of structure has been discussed in the community.

  • On a 16‑fader hardware mixer, this means I simply have too many sounds competing for too few strips.

  1. Triggers vs buses: no “one grouped drum channel” yet

  • Vangelis gets closer with routing: I can route many drum sounds to a single Percussion output or bus, which is what I want audio‑wise. But then this needs to be controlled with another bus, this is what increases the mixer crowding in comparison.

  • But I would love that bus/output to also behave more like a normal sequence or clip target, so grouped parts could be triggered and managed as if they truly lived under one “drum channel”, not scattered across multiple chains.

  • I realise that may be a big design change, but practically my problem is too many independent triggers and strips for a 16‑channel mixer, and not enough ways to bundle them into one controllable unit.

  1. APC Key 25 mapping feels non‑native and less flexible than MIDI Mix

  • The Akai MIDI Mix integrates well as a straightforward 16‑fader mixer; it’s easy to dedicate faders to drums, bass, FX, atmos and keep those mappings stable.

  • The APC Key 25, by contrast, doesn’t feel natively or flexibly mapped in either Oram or Vangelis.

    • Pads and knobs work as generic MIDI inputs, but I don’t get the same confidence tying APC pads/knobs directly and reliably to mixer strips or specific sequences.

    • In practice, the APC feels less like a first‑class controller and more like a “nice extra”, whereas the MIDI Mix feels solid and predictable.

Altogether, this means Vangelis has more potential and nicer tools, but for my current live workflow it actually feels more crowded and fragile than Oram on the mixer/controller side.

Workarounds I’ve tried (and their limits)

Across both builds, I’ve experimented with:

  • Group buses via Audio Out

    • Creating dedicated Percussion/Bass/FX/Atmos BUS chains and routing instrument chains to them via Audio Out, so I can ride one fader per category.

    • This helps reduce mixer clutter conceptually, but the sub‑chains still appear as independent strips and there’s no visual grouping/collapsing yet.

  • Printed / sampled composite kits

    • Exporting complex multi‑engine drum textures to WAV (via Ubuntu/Audacity) and re‑importing them into a sampler, to consolidate many sounds into fewer chains.

    • This reduces active chains but locks in sound and FX and removes a lot of live tweakability, which is a big part of why I use Zynthian.

  • Scenes, groups, ZS3

    • Using ZynSeq groups and sub‑snapshots to start/stop multiple sequences while routing audio to buses.

    • This helps with “who is playing”, but it doesn’t, by itself, solve the mixer‑side crowding or the desire for a single “drum channel” that truly bundles triggers and volume.

These workarounds tell me the system is powerful, but they still feel like patches around a missing higher‑level grouping concept, especially for live performance on limited hardware.

What would really help for live workflows

Based on this experience, a few things would make a big difference:

  1. Grouped / collapsible mixer channels

  • Ability to define groups like Drums, Bass, FX, Atmos, with a main strip and sub‑strips that can be folded away in a performance view.

  • In a live context, I’d ride the group strip; on screen, I’d expand to adjust sub‑channels when needed.

  1. Pinned bus strips and a performance‑focused mixer view

  • Being able to pin key buses (Percussion/Bass/FX/Master) so they stay visible and mapped, while other chains scroll underneath.

  • A distinct “performance view” that shows only the key strips (group buses plus a few featured chains) and hides or collapses everything else, with a separate “full mixer” for sound design.

  1. Better integration for controllers like APC Key 25
  • More native‑feeling mapping support for APC‑style controllers: predictable ways to tie pads to sequences/groups, and knobs/faders to mixer strips and buses, similar in reliability to how the MIDI Mix feels in practice.
  1. Trigger + bus unification, if possible
  • Some way to get closer to the Oram behaviour where multiple sequences can effectively live under one channel and be driven by a single pad/column, but combined with Vangelis’ stronger routing, so I can have both grouped triggers and grouped audio without exceeding 16 mixer strips.

Optional future idea: “multi‑synth sequence box” on a single channel

One more idea that could solve a lot of my workflow problems without forcing me into printed WAVs:

  • Imagine a sequence “box” (one ZynSeq clip) that can host multiple synths or samples inside it.

  • On the mixer, this appears as one channel/strip (for example, “Drum Box 1”), and on the pads it’s one trigger — start/stop that whole rhythmic group.

  • Inside that box, each sound (kick, snare, hat, stab, etc.) is still linked to its own engine or sample slot, with its own FX and parameters.

From the user side, it could work like this:

  • I drop different synths/samples into a single sequence container.

  • I can set it up either as a key‑based sequence (different notes triggering different sounds) or a pure beat sequencer specifically for rhythms.

  • If I long‑click on the sample/synth name in a sidebar, I dive into the advanced controls/FX for that one sound, even though it is still part of the same sequence box and still lives under the same mixer channel.

This would:

  • Let me build my own custom “drum kit” or grouped atmos/noise set by pulling sounds from different synth engines and dropping them into one sequence.

  • Give me one grouped channel and one pad trigger for that kit, while still allowing per‑sound FX and parameter editing inside the box.

  • Avoid the extra step of exporting everything to WAV on Ubuntu and re‑importing it, while still reducing mixer crowding and trigger overload.

I realise that’s a bigger, more future‑oriented concept, but it’s the kind of “sequence‑grouping instead of just channel‑grouping” that would directly address my issues with too many sounds on a single 16‑channel mixer in a live set.

Right now, that’s why I’m continuing to prefer Oram for performance, and using Vangelis mainly as an experiment platform. I’m very happy to keep testing new builds and routing ideas and to share more concrete examples if it helps clarify how these designs and controller mappings behave in a real live set with limited hardware faders and pads.

I do also acknowledge that my goal of keep the rig lightweight and compact is the reason for my workflow bottle necks. I’ll post photos tomorrow if I remember to bring my tripod home

4 Likes
10

Thanks a lot for your detailed and very useful report.
Some comments:

Could you explain with more detail your exact workflow with Oram’s sequencer?

Indeed, if you don’t create mixbuses, the mixer is not so different . Having the chain’s mixer controls fully integrated as a “chain processor” makes things more coherent and MIDI learning mixer controls is much easier. Could you explain what aspects of Vangelis mixer do you feel “overwhelming”?

Sorry, i’ve not an APC Key 25. I’ve the MIDI Mix and the APC40. Both are integrated quite nicely, specially the APC40, that currently is a “reference” driver.
Regarding the “APC Key 25”, could you explain with detail what you don’t like about the current integration. The developers of this driver would find useful your report.

Could you elaborate about this? How do you manage this in Oram?

Thanks!

3 Likes
11

Thanks a lot for your detailed and very useful response. The questions help me structure my thinking much better.

1. Oram sequencer workflow

In Oram my basic live workflow is:

  • I treat channel 1 as “Drums”, with several patterns and samples effectively living under that one channel.

  • On ZynSeq I set up multiple patterns that all send MIDI to channel 1, each pattern being a different drum pattern or variation.

  • On the APC Key 25, one column of pads (or a small group of pads) is effectively my “drums launcher”: pressing a single pad starts or stops one pattern on channel 1.

Under Oram I’m also able to stick multiple samples into a single sequence on channel 1, even though those samples each live under their own bus or strip in the mixer.

Concretely:

  • I have several drum samples or chains, each with its own mixer presence, processing, and bus or strip.

  • In ZynSeq I build one sequence on channel 1 that triggers those different samples on different notes or steps.

  • From the APC Key 25, a single column of pads can start or stop that one sequence, which in turn plays all those samples.

So from my point of view:

  • Mixer: multiple samples, each under their own bus.

  • Sequencer: one channel‑1 pattern that owns them.

  • Controller: one pad or one column that drives that combined pattern.

That is the behaviour I am trying to preserve: multiple samples and chains, but one sequence plus one trigger surface for that family of sounds.

2. What feels overwhelming about the Vangelis mixer

I understand what you mean that Vangelis is not so different if I do not create mixbuses, and I like the idea of the chain mixer being fully integrated as a chain processor.

The parts that feel overwhelming for me when I start juggling drums, bass, FX, atmospheres, and so on are:

  • More visible strips and routing options on screen at once. I quickly end up with drums, bass, lead, atmospheres, FX, additional chains, or mixbuses. In Vangelis this tends to show up as a lot of mixer strips, each with its own controls and routing.

  • I find myself spending more attention on “where is this chain routed, which mixbus is it in, which strip am I looking at?” instead of just “this is my drums fader; this is my bass fader.”

  • Because I am trying to keep everything within 16 mixer strips, I get nervous about using more mixbuses, even though they are powerful, because it feels like I will run out of strips faster than on Oram.

So conceptually I like the routing flexibility very much, but practically the combination of chains, mixbuses, and many strips starts to feel crowded in live exploratory use.

3. APC Key 25 integration

I know the APC40 is currently more of a reference device, and my issue is less about bugs in general and more about how the APC Key 25 maps to my live workflow.

On Oram I am used to a simple mental picture:

  • One part of the APC pads = pattern triggers, especially for drums on channel 1.

  • Faders and knobs = straightforward control of the few main mixer channels I care about.

On Vangelis, with the same APC Key 25, I do not yet feel a clear default “live set” layout: which pads are my drums patterns, which are my other sequences, and which faders or knobs are grouped outputs.

4. Knobs K1 through K8

One specific detail is that on my unit, the knobs K1 through K8 do not seem to program or MIDI learn into Zynthian on either Oram or Vangelis.

  • They send MIDI, because I can see activity.

  • But when I try to use MIDI learn on mixer controls or chain parameters, Zynthian does not pick up K1 through K8 as learnable sources.

  • This is true for me on both sides: Oram and the Vangelis test image.

  • In the current state, they only seem to work as a kind of parallel to the volume control bus on the mixer, rather than as independently mappable controls.

  • I also have not found a way to independently map K1 through K8 to separate functions.

So from a user perspective, the eight knobs feel either dead or very restricted compared to what they could potentially do.

5. Wish: K1 through K8 as sequence master controls

One workflow feature I would find super handy would be to use K1 through K8 as master level controls for each sequence column, even if each sample in that sequence has its own bus assigned.

What I mean is:

  • Each sequence column, for example a drum pattern, ghost pattern, bass pattern, or atmosphere pattern, would have its own master level.

  • The underlying samples or chains could still live on their own buses and be mixed or processed individually.

  • Turning K1 through K8 would let me fade a sequence in or out, or adjust its overall level, instead of only having a hard start or stop behaviour when I trigger or mute a sequence.

This would give me:

  • More musical control, because I could gradually bring sounds in and out instead of just turning them on or off.

  • A way to treat each sequence column almost like a little master for that musical layer, while still keeping my main mixer under control.

If K1 through K8 could be mapped to sequence column master levels, or something similar, that would make the APC feel much more native to how I am trying to use ZynSeq and the mixer.

6. Multiple samples on channel 1 in Vangelis crowd the launcher

Another specific difference I am seeing in Vangelis is this:

  • When I add multiple samples to channel 1 in Vangelis, they show up as four separate pads, 1 through 4, in the launcher, even if they are all part of sequence 1.

  • This makes the launcher feel crowded very quickly, because one logical drums sequence ends up occupying several pads instead of one compact sequence slot.

This is one of the big differences in feel for me between Oram and Vangelis.

In Oram, one logical grouped sequence can stay feeling compact from the controller side.

In Vangelis, that same idea seems to spread outward into more launcher pads, which makes the launcher area feel crowded faster than I would like.

7. Grouped triggers plus grouped audio without exploding the mixer

Putting it together, the thing I am looking for is:

  • Something close to Oram’s behaviour where multiple samples and sequences for drums, and maybe other parts, can effectively live under one channel and be driven by a single pad or column.

  • Combined with Vangelis’ stronger routing, so I can:

    • Group triggers, for example several drum or bass patterns launched together or from one pad or column.

    • Group audio, for example all drum chains routed to one mixbus or output.

    • Still keep the visible mixer at or below 16 strips.

In Oram I currently manage it roughly like this:

  • Channel 1 = drums.

  • Multiple patterns in ZynSeq target channel 1 and can contain multiple samples.

  • APC pads trigger those patterns.

  • Mixer shows one main channel strip for that drum audio group, and the launcher feels compact.

In Vangelis, I would love to:

  • Keep a similar “one grouped drums output per instrument family” idea, such as Drums, Bass, Atmos, FX.

  • Use mixbuses or chain processors so that all drum chains go to one Drums strip, all bass chains to one Bass strip, and so on.

  • Have a clear way for APC pads to trigger patterns within those groups, so that one logical sequence does not explode into multiple launcher pads.

  • Use K1 through K8 as sequence masters, instead of ending up with more and more separate visible controls.

8. I can provide visual examples

If it is useful, I can provide some photos or video of each system’s functionality to help show exactly what I mean and what behaviour I am witnessing in practice.

It will take me a bit of time to compile and arrange all of that material, because I will have to switch back and forth between Oram and Vangelis to capture everything in a consistent way.

Thanks again for looking at this. I really appreciate the thought being put into Vangelis and the controller side of things.

1 Like
12

PS: In fairness, there are many changes within the Vangelis image and it feels like there is quite a bit of relearning the system. I have only played with it for about 5 hours so far, so it is entirely possible that I missed something or made a mistake in how I set things up.

13

I think that the main changes are about the sequencer and the chain manager, apart from that most of it are additional features. Main learning pills in that regard might be new encoder action assignments in certain contexts.

14

But how you get several stepseq patterns playing in the same channel at once? Or you play only one pattern per channel at once?

Regards

This samples are not loops, right? They are percussion sounds that you want to trigger from pattern. Are you using zynsampler for this?

I don’t understand why. If you don’t create mixbuses, you should have the same number of mixer strips in Vangelis and Oram. One mixer-strip per chain, right? Of course, if you start creating mixbuses, you would have more mixer strips.

OK! I understand you want to limit to 16 mixer strips because you want it mapped to the Akai MIDI Mix, right? So, what you would like is a way of grouping & filtering mixer strips, right?
Well, you are lucky because we already have some “filtering code” implemented for mixer strips. Indeed, if you would be using a Mackie controller, you would have access to these “filtering” features right no. I mean, the filtering is implemented (not the grouping!) and it allows filtering by “type”, so you could have a view with the “Mixbuses” only, or “MIDI instruments” or “Audio Input”, for instance. I know it’s not all you want, but it’s a first step. We could improve the code a little bit to show “mixer strips sending to mixbus1”, for instance, and this is already the “grouping” you want, right?

I fear a recent change on this driver has broken this functionality.
Read this and let’s try to convince the developers (@niels) to restore the original functionality :wink:

Regarding using the knobs for the mixer, i feel it should not be part of the driver, as it doesn’t “maps” very nicely. It’s more a “dirty mapping” to allow the controller do things it was not designed to do. But perhaps the driver could have a “mixer mode toggle” to allow this.

Regards,

1 Like
15

One thing that is a bit unclear to me is: Do you use a ctrldev driver for the apc key 25 or do you use it without a driver?

And is it the first version or mkII?

16

Oh, and would the multiple tracks feature per sequence (now gone from Vangelis) be of aid?

17

in Oram I assign them under the same channel and then assign notes (especially for the percussion elements). That channel is then that sequence. For example channel 1 is then sequence column 1

In Vangelis, I tried the same work flow. Which does work. But on the trigger pad each sample takes up its own pad instead of the sequence. So if I have 4 samples under 1 sequence columns 1-4 are then used, instead of just 1

18

I will have to check. I don’t have the system specifically in front of me at this moment. I can say definitively that I have not downloaded any outside or additional drivers. From my understanding the APC key 25 should be natively recognized (and it is for the most part, just unable to independently map the knobs k1-k8)

For me the best useage of these knobs would be to be able to map them as follows:
-K1 mapped to control the volume for Column 1 on the trigger pad
-K2 mapped to control the volume for Column 2 on the trigger pad
… and so on

19

yeah. I believe that’s exactly what I have run into with the Vangelis

20

Are you using zynsampler chains in the same MIDI channel?
Could you send some screen captures or pictures to better understand?