I have three zynthian kits with updated oram (green hearts).
When I select multitrack recording on main chain, all chains, which deliver audio signals to the main chain, are not recorded in the main chain.
On another kit (kind of productive kit), some are recorded on the main chain, but some aren’t, This special kit uses a multichannel input/output device, which is working correctly.
I can confirm this looks like a bug. I can reproduce it here. So that we don’t lose this, will you please report using webconf’s “Report Issue” button?
Expected behaviour:
the multitrack file contains all 5 audio signals (chain 1-4 + main chain)
The stream of the main chain containing the sum of all the single chain signals.
Actual behaviour:
Only the single chain audio streams are in the multitrack file, main chain recording is silent, but a silent audio stream is in the multitrack file.
Directly listening doesn’t help, you have to download and inspect the wav file.
It is funny, you could probably have made the bug report faster than typing here… Anyway, I did a bit of investigation and see that the cause of this regression is the internal normalisation performed by zynmixer. We added this to reduce latency and processing overhead. Multitrack recording works by specifying the destinations to monitor. The recorder is fed with the same sources as those destinations. Due to the internal normalisation, we no longer route chains to the main mixbus input and hence the recorder does not follow it. (It would record some other sources like the metronome and global audio player.)
We may be able to fix this by explicitly specifying the destinations to which main mixbus output are routed, e.g. system:playback.
Note that without multitrack recording enabled, the recorder will record whatever is routed to the physical outputs. This may not be desirable, e.g. direct routing of a chain to an output is not the main mixbus. I will take a look at that at the same time. (Possibly a similar solution but has some edge-case subtleties.)
[Edit] A simple solution would be to remove the option to set main mixbus to multitrack recording.
The functionality is not perfect but better than before. The output of each armed chain’s zynmixer direct output is fed to the audio recorder. This does not capture any post-fader effects but I think this is a reasonable compromise. The complexity of recording post-fader effects is quite high and this fix was simple. If a user reports an issue with missing post-fader effects we can review.
I’m bit confused know.
Because I’m using oram, will the “solved by @riban” issue in vangelis be merged later to oram?
Is vangelis kind of development for the “stable” oram or is it the development platform for a new release?
Anyway, I wrote a bug report for oram.
Regards
Yes. It will be merged after testing and being sure it doesn’t break anything.
Vangelis is the new development branch. We work in this branch to avoid breaking things in Oram.
Currently you can change from Oram to Vangelis and back to Oram without problems, and we will do our best to keep things like this. I mean, allowing to switch between stable and testing versions.
Anyway, in the next days/weeks we intend to start releasing stable Oram tags so users can move from one tag to the next without risking stability. It will be well explained when we do the first “tag release”.
Suggestion (to be discussed): sell it as feature, not bug. Why? Because, what exactly is the advantage of a post-fader effect compared to a pre-fader effect, if you want to do work on the recording later on in a DAW? If you’d NEED the post-fader effects in you’re recording, you always could send it to an extra audio chain with same effects as pre-fader effects, but you could also apply it during post-production in the DAW.
Another thing is the metronome. For post-production purposes, it would make life easier to have an extra track with the metronome signal (if metronome is ON) to synchronize the audio material during the post-production process. But as I see, it’s actually also in the main mixbus track. Hence, if you record only the main mixbus signal, the user will get a recording of the metronome too.
But the user’s intention was perhaps, to play with the help of the metronome, but have it not in the main mixbus recording. Hence, an extra track in the multitrack could exclude this signal from the main mixbus recording track. (It’s somewhat difficult to describe…)
But OK, I see, this is an extra discussion.
Yes, I concur. We can say, this is how it is and users can do with it what they will. You very rightly say that the effect can be reapplied in the DAW. I am aware that most sound engineers would apply many effects post-fader but I think most zynthian users would apply them pre-fader. (Indeed, until recently that is the only option they had!) So I thick this is a fair decision and one that allows us to move forward without substantial coding. (@jofemodo will be pleased to hear .)
I mentioned the metronome in my previous comment because it occurred to me when I saw its routing that this may be suboptimal, even though mentioning it could (and has) trigger attention and hence more development. For multitrack recording I thick the metronome is less of an issue because it appears in the main mix, not any of the individual chain stubs. For stereo recording then it may be desirable to avoid it being recorded. You can do this by using a chain as a record bus. You would route all the chains to the record bus chain and enable record on that chain only. You still hear the mix including metronome on the main mixbus but only record from the record bus. It is a bit of extra routing but works quite nicely without any code changes.
I think most alternatives amount to the same thing. If you want to hear but not record the click you need separate monitoring and record buses. Maybe offering to route the metronome could increase flexibility but I don’t want to do that without good reason and significant benefit.
[Edit] We have a dormant task to provide audio feedback for visually impaired users via the headphone / monitoring feed only. The metronome routing could follow a similar path. I want to advance that topic over the next year so this may fit nicely into that. We may also desire the ability to route click to specific output, e.g. just send click to the drummer’s headphones and everyone else follows the drummer.
.)
For multitrack recording I thick the metronome is less of an issue because it appears in the main mix, not any of the individual chain stubs. For stereo recording then it may be desirable to avoid it being recorded. You can do this by using a chain as a record bus. You would route all the chains to the record bus chain and enable record on that chain only. You still hear the mix including metronome on the main mixbus but only record from the record bus. It is a bit of extra routing but works quite nicely without any code changes.