OK. Understood. There is some confusion with mixer channels and MIDI channels. i will fix ASAP.
Thanks for the feedback!
3 Likes
This can be ignored, seems thatās hardcoded behavior of the launchpad itself
The Drums/Keys/User are all ācustomā mode. The behavior can be adapted (via a web tool), but it seems only of the 8x8 grid buttons. The top and side buttons can only be enabled/disabled as octave down/up.
When checking with midi monitor, they send nothing at all, only the User mode does.
Nothing Zynthian can do about it as far as I can see.
1 Like
Sorry if I add too much noise here 
I was thinking, if the launchpad device definition could take into account which Mixer channel is currently active at any moment, it could automatically show the ā2nd pageā if any of the Mixer channels from 9..16 is activated (theoretically that would scale to infinite columns).
Starting from the first column, you would have to press 8 times arrow-right to go to launchers for column 9..16, but thatās not so bad imo.
You are right, @rv5 . AFAIK, these buttons are only available as MIDI from sesiĆ³n mode.
Regards
1 Like
The initial implementation of this clip launcher is based around the idea of using pre-recorded samples, e.g. downloaded from a sample library. During zynth club last week it was suggested that an audio record option would be useful. This would record audio into a clip, in sync with the loop, tempo, etc. This sounds like a good idea, not dissimilar to a looper (like sooperlooper) but it raises questions which I would like all and any of you to consider:
- What audio source would feed the recorder?
- If selectable, how would we select the audio source?
- How would we start / stop / toggle record?
- When would recording start and stop, e.g. would it be constrained to a single loop? Would it start immediately or at start of next loop?
- How would we define the duration of the recording? (There may be an implicit duration for the scene that could / should be inherited.)
- Would the recording be one-shot or looping?
- If looping, would it overwrite or add to existing recording?
- Would there be undo options, etc.
Getting a feel for what users want may help inform what a solution may look like. We already have Sooperlooper which is an excellent and very flexible looper. We may be able to leaverage this or may want to reuse the existing audio recorder or maybe we write yet another moduleā¦
Answers to all or any of these questions or any I havenāt thought of are appreciated.
2 Likes
Good morning @riban, thanks for taking up the idea. Iāll try to answer these questions:
I would say, that the recorder may be a module of the ZynSeq (later on āZynbletonā) clip inside an āAudio Chainā. That way the sound source would be already clear (the input of that audio chain or other chains routing to it).
This way the recorder would be found on an audio chain exactly where you usually enter the pattern editor on an instrument chain. I would implement it the functional equivalent to the pattern editor inside the sequencer when entered from an audio chain. I donāt know how it will be exactly in the new Zynbleton. From there we could record using the transport buttons like in the pattern view.
The main thing to consider is how you (physically) start/stop the record. If youāre not blowing an imaginary air flute there are chances you have to utilize some other body parts to play some instument. So there has to be some punch-in and punch-out-helpers. So things which can work:
- Punch in and out within loop predefined in beats per sequence
- Loop until manually stopping the record while overdubbing (NOT replacing). (This would work either with punch-in at loop start or immediately because no audio information is lost)
- Record a one shot until manually stopped (but played back synced to the sequencer tempo).
Of course I would love to have to choose between the possibilities as an option. If it should be only one default behaviour I would opt for the second variant, because itās also possible there to record phrases which are somehow crossing the loop point.
It would be great, but the only scenario above where it would be really helpful is when you overdub the loop.
How would I use this?
I would create some instrument and audio chains (drums, synth / bass, guitar), then type in or record some midi patterns for drums and synth, then I would use the looped overdub function to record a bass loop and then use the oneshot function to record some guitar solo shots, which can be then triggered by the sequencer.
2 Likes
I had thought of putting the audio clip launcher into the audio chains. These are empty when the launcher is shown. I am not sure it makes sense though. It could be confusing to have launchers capable of creating sound on the same chain that is used for a mic input and it just adds to the complication to offer an option to add a launcher to an audio chain. We could use the same mechanism for routing audio to a clippy chain, i.e. select the audio output menu from each chain and select clippy as a destination. This would be irksome if you had to do it for each clippy chain, so it would probably make sense to do it globally, e.g. chain 1 feeding clippy which would result in any clippy chain recording chain 1. It may also be desirable to be able to select the sources from within the destination chain. Currently, you select the destination from the source chain but if your workflow is recording from other chains, it feels awkward to go to each to select it.
Iām not completely sure if I can follow, probably because I may not exactly know where the audio clip launcher (a.k.a. clippy?) is located routing wise.
In my imagination the clip launcher would just appear in the sequencer for each audio chain as a corresponding concept to the instrument chains patterns. It would record from that audio chain input and it would playback through that specific audio chain output.
Chances are high I misunderstood something, because I did not saw any urge to define sources or destinations within that concept. Routingwise I imagine something like the tape-in/tape-out connectors of a mixer.
EDIT: After re-reading your comment multiple times I see you are adressing both of the concepts. So, I would prefer not to have a clippy chain to route to, but rather have clip launchers on each āpadā on each track of an audio chain.
I would not find it confusing to have both audio input and one or many recorded sound source, maybe the best approach would be to mix the two sources anytime (playback input and recorded source simultaniously). Itās rather like the mixing desk where the input is connected, but the tape machine to tape-in as well.
We currently have an audio recorder that will, by default record the main mix output as a stereo wav. There is the option to arm each chain which will add that chain as a stereo track within a multitrack wav. So the global recorder will record the output of each armed chain. This is not what we want for the clip launcher. We want to constrain this to a stereo file. We also probably donāt want such an awkward mechanism for arming which chains are recorded. (This may be simplified in the futureā¦) My idea would be to have a stereo audio recorder that can be enabled from any clip control view. (Clips are shown as launcher buttons in the launcher gird and bold select will take you to its control view.) So toggling record in a clip view will toggle this stereo recorder and the resulting file will be the clip of the currently selected clip. (Challenge: what to do when exiting the view, e.g. going to another clip view whilst recording? Maybe donāt allow and stop recording when exiting view.)
My idea of audio routing was to allow you to see a list of all audio sources (chain outputs) and be able to select which are routed to the recorder. So, if want to record a mic that is connected to input 1 and routed to an audio chain, you would select that chain from the list of source to the clippy recorder.
Exactly this was my idea, too. Bold press on audio chains grid clip opens ādistinctā audio recorder instead of pattern view. Multiple clips to record per audio chain are allowed. The audio recorder offers options (recording length in beats/bars), type [one loop/loop overdub/one shot]ā¦). No routing necessary, because audio chains audio-in/audio out are already set (One could also record mono/stereo tracks depending on audio chains channel count).
This. One can allow recording until the end of the sequence though, but not necessary.
In a lot of software, it is possible to arm-record multiple tracks at the same time and as such do a multitrack recording of audio clips
Ideally, each track would by default receive all inputs (except internal), but allow a setting to specify which input, and a record-enable toggle button on the screen (e.g. below each track)
Both have their use. Perhaps a shift-record key combo
if clip already exists (overdub), if not record until recording is stopped (auto-length / quantized). Ideally a setting would allow to restrict loop length to a predefined length as well, I think flexibility is key here as a lot of use cases may vary.
looping by default, again a global setting would also help some other use cases i guess.
both use cases make sense to support
I will look forward to this very much. A beautiful combination of Audio(sequences) and Midi-sequences
This seems very nice way to do it! It would be good to know that you could make a clip from multiple audio sources.
I would prefer looping if not both available!
I would prefer adding!
In addition to the one person user scenario, i have a dream of using this āsoon to be releasedā Zynbleton with audio clips/loops as an extension of 2-3 person jamming/performance. There would be drumpatterns and other patterns pre-made, a framework (the launcher) for the musical piece, and the possibility of looping improvised parts and working on top of them. But thats a dream that might never come true, because even if the hardware and software was perfect, i would still be needed to control it all, and i feel that this would be a task that would be to demanding for my mental capacity. But the someone could put AI into this as well, and i could sit back and let it all happen by itselfā¦.
I really like all suggestions here very much. But the challenge of this kind of multitrack recording would be:
- How do people without a touchscreen access the onscreen record buttons?
- How do you specify the properties of the clips upfront (loop length, record behaviour, e.g. loop/oneshot, input)? So youād have to go through these clips upfront to specify their recording behaviour anyway.
That said, I wonder if one wound have to choose between multitrack recording and the ease of having clip I/O aligned with itās audio chain I/O. Maybe Multitrack recording (of armed chains to seperate wav files) would be just another project.
I think i understand the complications a little bit - maybe the one audio chain that the pad is associated with would be armed by default, and other could be armed by choice up front? and then i think go to the clippy thing as a normal Wav (not multitrack). The other record settings and loop specifications could also be defaulting to some choice made by user, and then altered on the fly if needed (since this would be an interrupting and time consuming thing to do)
Iām unsure, but i think that a pedalboard or launchpadthingy and some midi-learning or a dedicated controller-driver could do it?
I must state that i do NOT have very much hands on experience with this kind of things, and i therefore make excuses if some thoughts put forward here shows some of my immature state
1 Like
I donāt intend to provide multitrack recording as part of the clippy loop recorder. I mentioned the exsiting multitrack recording so that we are aware that we already have an audio recorder with some functionality and that we are considering how to provide another with other functionality as well as considering we also have loopers, etc. I donāt see an advantage to multitrack recording or playback within the clip launcher.
1 Like
I think the question is what kind of concept it should fulfill. As much as I would also like the multitrack idea Iād be afraid that any step towards it would be complicate the ways to specific clip/loop launcher actions.
The advantage of recording and playing back singletrack recordings from the sequencer are that you always know where you are in the recording process and no extensive setup is needed because itās all inherited in the audio chain already. So it provides a quick access.
The way it would work like outlined above would be: enter recorder from the sequencer clip, maybe specify the loop length and probably the choice between loop/one shot and record ahead.
Also I would vote against every concept that would rely on external devices or would not be accessible from every possible zynthian.
Just to clarify, i certainly agree on this (except i do not know what the first Zynthian really was, and i can accept that something is left behind in the process of moving forward).
I think in regards to what initiated this trajectory:
There would be a long-press on the pad/scene (iām still confused about what is what) with the choices of loop length, record type, loop behaviour and such)?
We aspire to make every core feature in zynthian available on the main platforms:
- Official V5
- Official V4 (and lower)
- Touch only
The documentation is written to allow these three UIs to be filtered.
Regarding recording - not multitrack. That is already implemented for the main audio recorder and makes little sense doing it for clips.
Workflow for recording should be simple to understand and probably (as suggested) mimic the pattern editor recording. When you access a MIDI clip, you see the pattern editor grid and can record live, whilst playing in loop mode. All notes within a record session may be removed by an undo option. The recording doesnāt stop when leaving the pattern editor (but maybe it should). So a similar audio workflow might be:
- Bold select clip to show control view
- Existing clip is shown or empty clip
- Ability to toggle record
- Ability to set duration of recording (in beats / bars?) for new recordings, or inherit from scene
- New recording creates new audio clip file
- Ideally, an undo option to restore previous recording (though I donāt think this could be multilevel, just one undo to restore previous recording)
- Loops in addative recording
2 Likes
This totally makes sense.
I think not to be allowed to leave the view during recording would be an acceptable shortcome. If you would allow to leave the view it would be either lead to infinite one shot recording or to infinite destructive overdubbing with plenty of noise until you manage to enter the view again.
I think allowing to leave the view while recording would only be reasonable when doing a loop recording with automatic punch-in and out. But I also donāt find any huge advantages to leave during recording anyway.
Re looping process, and this being Linux, I think you should aim for as much configurability as possible for this function, rather than trying to nail down an opinionated canonical setup. Iāve never gotten good at looping, but Iāve messed around with enough loopy stuff to see that they all try to include some degree of confgurability as far as that stuff.
So for instance, triggering record - variously, you might have users who just want the thing to trigger exactly when they stomp, and youāll have others who want it to wait for the next beat, others still that want it to wait for the next measure, others that want it to wait for the next loop through the chosen sample, and even others who, even if they stomp it up to 30ms after the last beat/measure, want it to start recording a loop at that measure, backfilling with silence up to the moment of the stomp, or else keeping a running recording stream that it just ācuts inā at the right point, which would be the slickest.
Each of these would have their utility, and the only one that is difficult is the backfilling or live scratch recording one, though itās always seemed to me that keeping a constant recording buffer going would make manipulations easier, I think? Way more advanced coding than I can currently do. :>
Mainly, aim for as many options as you can conceive of, because it is our job to be the system that does not demand the user make do with a hobbled system, just because their devs have no imagination. :>