@everyone We are honing in on Oram release. If you are suffering any issues that are not reported in this list then please add a github ticket by clicking the “Report Issue” button in webconf dashboard or, if your issue means the dashboard is not availble, report using the template.
I know there are lots of you already testing Oram so your help to capture and fix any outstanding issues before release will be very welcome. Anyone who is not yet using Oram and wants to test it before it becomes the stable release, please do. We recommend flashing the image to a spare uSD card for test purposes.
Come on! Let us pull together and push over the line. Oram is good! Oram is great!
The only issues I’ve noticed when testing oram are not actually related to oram, but rather V5 (wifi not working, because of new case) and pianoteq 7 demo seems to be dead after I connect it to the Internet and restart device (if offline on fresh install, it seems to be fine). Haven’t checked with licensed version because I do not have one yet.
I’ve several V5 working with WIFI without issues. It’s true that signal is not the best because of the metal case, but we can’t do little bit about it, except trying to be as close as possible to the router, or use ethernet cable. A WIFI dongle could serve as a last resource solution.
Anyway, when designing the V5 we had to choose between having a good, hard metal case with good EM isolation, excellent thermal dissipation, no fans, no slots, no dust, etc. or having good WIFI connectivity. I had no doubt. Having a good WIFI connectivity is important, but is not zynthian’s highest priority. Design is a compromise.
This doesn’t seem right. AFAIK, Pianoteq test version shouldn’t get blocked because of lack of connectivity. But it get blocked after 20 minutes
About being close to the router, trust me I’ve put zynthian next to my router and this did not changed anything
Maybe this is connected to PL WiFi bands configuration, but for me it only works when wired.
About pianoteq you mean that that limit is 20 minute in total time played on the device or just since opening plugin? I thought that it resets after plugin reload.
(On a side note when I’ve checked in vnc there was an info alert in ptq gui that I am running older version).
Nice. Can’t wait for the new release.
The only issue I’m seeing is zynthian getting disconnected from webconf when connected via Ethernet from pc to both raspberry pi400 and cm4. It does that at about 5 to 10 minutes after connecting.
I’ve described some other issues I have in the issue tracker.
One, is about midi learning of plugins in the main chain with external midi controller which are set to multitimbral mode - it is not working correctly, but it is working if the device is not in multitimbral mode.
Two, the same behaviour for zynthian switches, when they send midi CC (for example to switch on of plugin effects in the main chain)
Three, some weirdness of the pre-fader audio signal flow in the main chain (incoming signal seems to be split into audio signal directly to the fader, and another one through the plugins).
I edited the description of the ticket text in zynthian’s issue tracker, because it was difficult for me to describe correctly.
And, I’m also quite excited awaiting the birth of a new release
Some of this may be misunderstanding the signal flow. We need to improve the docs but may I just check you have read the various guides in the wiki including the “experimental” guide?
I will address your tickets in the issue tracker but your comment about wierd signal flow does not seem to have been reported so maybe a few words here might explain…
Each chain in Zynthian may be MIDI only, Audio only, MIDI & Audio, Synth, Generator or special. They are mostly very similar with some configs to adjust behaviour.
A MIDI only chain allows routing of MIDI inputs to MIDI outputs through zero or more MIDI effect plugins. Each acts individually so you could end up running the same signal through multiple chains and end up with undesirable duplicate events - so beware!
An audio only chain allows routing of audio inputs to the audio mixer through zero or more audio effect plugins. Again, each acts individually so you can end up with the same audio input being fed to various places, e.g. audio input 1 may go to a reverb in chain 1 and also directly to the 2nd mixer strip via chain 2.
A MIDI + Audio chain does both of the above which is useful for some workflows that temporarily escape me but are really quite cool. (I must try to remember.)
A synth chain allows routing of MIDI inputs through zero or more MIDI effects to a single synth engine. The audio output of the synth can then pass through zero or more audio effects before going through an audio mixer strip.
A generator chain is like a synth chain but does not have MIDI input. Its audio is generated automatically, e.g. a tone generator.
Special chains are, well… special. They don’t really fit neatly into the Zynthian architecture. They may have audio and MIDI inputs and outputs and basically do their own thing then we squeeze them into a chain to allow input and output routing and control of parameters. (I don’t like them but they are very popular!)
The routing around the audio mixer is interesting… An audio generating chain (audio / synth / generator / special) without audio effects connects directly to the audio mixer (assuming its audio output routing is set to “Main” - the default). If there are any “pre-fader” effects then they are inserted before the chain’s corresponding audio mixer strip input. If there are no “post-fader” effects then the chain’s post-fader audio passes internally within zynaudiomixer to the main mix bus. If there are chain post-fader effects then the corresponding audio mixer output is fed to through effects to the audio mixer’s main mix input where it is combined with the other (internally normalised) strips. That is okay and fairly intuitive. Similarly the main mixbus post-fader effects are simply inserted between the audio mixer main output and the selected physical audio outputs. It is the main mixer pre-fader effects that are interesting…
These have to be inserted between the chains post-fader (direct) outputs and the main mixbus input. So they appear similar to chain post-fader effects but the main mixbus effects chain is fed from the final point of each chain’s outputs - which may be the mixer output for that strip of, if there are post-fader effects, it will be the last effect(s) in that chain.
Look at the picture in the wiki that shows signal routing. It is far easier to understand by looking at a picture than reading all these words.
first of all, thank you for the explanation. I think I understand the signal flow good enough to be confused, to explain myself I made a screenshot of patchage’s screen.
I do not use the audioplayer, nor the metronome.
To visualize my problem I made a screenshot of a patchage’s jack audio connection around the input of zynmixers main mixbus input.
As you can see I have two plugins inserted: “gain-01” and “gain-02”, the first is the pre-fader plugin as you described. The latter is the post-fader plugin.
“gain-01” is collecting all outputs of all single audio chains ( in my example 2 stereo outputs) connected to main mixbus.
If I turn down the plugin’s gain control of “gain-02” (post-fader), I can reduce the volume of the output of the main mixbus to -40 dB and I can hear nearly nothing anymore - that’s fine.
If I reduce the plugin’s gain control of “gain-01” I would expect to get the audio signal reduced to -40 dB.
But instead I can hear the clear output signals of the audio streams.
Why?
This is what I meant with “weird” signal flow. Because from jackd’s point of view there should be no signal. The only possibility is, that there is an internal audio signal flow inside zynmixer, which makes me hear the audio signal from the outputs of the two audio chains.
Thanks for the description. I can’t see enough of the signal flow from the truncated Patchage screenshot and don’t know what the full snapshot is. Post the snapshot so that I can reproduce it.
Issue: try to reduce the gain in the pre-fader gain plugin (“gain-01”) and compare to the reduction of gain with the post-fader plugin (“gain-02”).
On my freshly updated oram the pre-fader gain plugin seems to be bypassed.
I can also make a video if it is necessary to show the issue. If you can’t reproduce the issue, something happened during my daily made update process of “oram”.
There is a gain plugin, pre-fader in the main mixbus. This is the level adjustment you are saying is not operating as expected. To simplify my text, I shall call this GAIN_A.
Chain 1 has PD with patch “generative relaxing”. This has default routing to main mix bus. When this is unmuted then its audio level is adjusted as expected by GAIN_A.
Chain 2 has Calf Monosynth feeding Calf Vintage Delay. The audio output routing of this chain is not going to the main mix bus but instead going to chain 3. Adjusting GAIN_A has an effect on this signal. GAIN_A is a mono gain control so the left and right channels are summed which may reduce the impact on this signal.
Chain 3 is an audio chain with physical audio inputs connected to its pre-fader Calf Reverb. Also connected to the Calf Reverb are the direct outputs from chain 2’s mixer strip (because of the audio routing described above). The Calf Reverb feeds audio mixer strip 3 and audio mixer direct output for strip 3 feeds GAIN_A (because it is main mixebus, pre-fader). Audio applied to physical inputs passed through this chain and is affected by GAIN_A.
The amount that GAIN_A effects signals may seem incorrect but I am struggling to see the effect due to the combination of effects (reverbs, delays, etc.), audio routing and use of mono gain effects. I will do some tests with different effects to simplify the impact of the audio whilst maintaining the configuration / signal path.
Tip: If you use an audio chain as a group then you may find it advantageous to rename that chain. Currently your Reverb chain is called, “Audio Input 1,2” and appears so in the audio output routing of other chains.
[Edit] Okay - I simplified the configuration and can now see the issue. (BTW you were right with your diagnosis but it was challenging to see it with such a complex snapshot.)
Chain 1: Special chain with MDA TestTone. Disconnect audio out from main mix. Connect audio out to Chain 2.
Chain 2: Empty audio chain, routed to main mix (as per default output routing).
Add 2 instances of Gain 2x2 to Main Mixbus, pre-fader, in series
Observe tone is present on both outputs
Within patchage, manually disconnect one audio signal between the two Gain 2x2 plugins.
Expect no audio on main output for that channel but actually it falls in level
So this proves that the internal normalisation is not being disconnected when a chain is routed to another chain. (It was this extra chain-to-chain routing that was missing from the initial bug report!) BTW this may also explain why some users (like @wyleu) saw their outputs hotter (higher level) than expected.
I will ensure there is a suitably worded ticket and investigate zynaudiomixer. Thanks @gitnob for persevering.
[Edit] It should now be fixed. @gitnob please retest.
@riban, I just tested the pre-fader/post-fader issue with a fresh update.
It’s working as expected now. Thanks a lot
For the complexity in trying to explain: coming from linux I was connecting jack audio and midi signals by “hand” since ages (with patchage or catia), it seems not to be too complicate for me. I could have read the patchage image and could have said, what you did on zynthian to get the same image. Forgetting, and that’s my fault, that other users probably have a different look at it.
And sometimes, you find some irregularity and cannot directly reduce it to a very simple patch.
For example the other issue I have: midi learning in main chain; step by step I could reduce it to a specific arrangement, which is not very complicate. The question for me as a user/tester(?) is, when to raise a ticket. From the first appearance of the first irregularity on, or only after a very intense investigation of the error?
All in all, I am happy for this discussion(s), hence I will learn more and more about the details of how zynthian is working. And thank you for trusting in me, who’s trying to help with the bug hunting.
I want more bugs reported. It is rather frustrating when a developer hears of a bug that users have been suffering for years but have not reported. Some uses believe that if they have experienced an issue then the developers should already know, bit this is usually incorrect. (If we knew then we would try to fix it.) Others worry about their credibility in reporting issues. I always want unexpected behaviour to be reported, even if we ultimately decide to not fix it.
We are close guys… There are very few unresolved issues in the tracker flagged as Oram dependencies. Please check to see if we have asked for updates from you, e.g. we cannot reproduce an issue or need more info to diagnose. Also, please test, test, test and report any issues you find.
A quick update on navigation - access to admin menu from a V1-4 has changed to long press of LAYER. ZynPad can now be accessed with bold press of BACK.
We are starting to look at documentation. There are a few attempts at documenting all the changes from the past couple of years (V5, Oram, etc.) which we need to consolidate. More on this soon…
ciao Riban
I rechecked and loaded all my snapshots and I noticed that after loading sometimes I see shows the snapshots screen instead the mixer screen; it is a minor issue.
After loading many times snapshots, it happened loading Sf2 with presets, presets screen is white; switch off, switch on all works perfectly.
I activate RPi headphone from WEBCONF and system freezed and after switch off, switch on, it does not boot
