Thanks @jofemodo, for your consistent effort in perfecting gradually Oram, towards a prospectively full and reliable Pi5 support. I am confident that the updated hardware platform will work flawlessly with Zynthian in the end.
There seem to have been quite a few low-level changes between Pi4 and 5, which must be challenging to address from a developer’s standpoint.
Enjoy your hardly earned family holidays!
All the best.
These last days I’ve performed a couple of fresh install with different setup, Pi3, Pi4, various displays and audio gear. I believe it’s fundamental to give to newcommers the best experience with Zynthian, starting from the installation process.
I had some issues with previous release but I didn’t really report them. I was hoping improvements and …
So far, it’s excellent. Bravo.
I’ve noticed that Zynthian switch to the internal headphone output (with Pi3 and Pi4, I don’t know with Pi5 because of the lack of analog audio output). It’s good because at least UI starts wich is less frustrating then the error splash screen.
But can have some disadvantage
Here is a closed issue " Enable hotspot when error screen is shown and no wifi/wired network is configured/available"
I’ve just done a fresh install with a headless Pi3 + Dac Hat and no ethernet. System looks like it is up and running but, unfortunately, Zynthian is not remotely accessible. And, as is, unusuable.
So, I suggest an imporvement: When ever no wired connection is available at first boot, Zynthian should start in Access Point mode.
This is one of my pet gripes! If you don’t tell us then don’t expect us to know and magically fix stuff. Please, everyone, report bugs and feature requests in abundance. I would prefer too many bug reports than we can handle than none. @jofemodo is a wizard but, unfortunately, not yet a mind reader (except maybe my mind!).
@riban is the preferred method to post issues here or open tickets? If it’s a ticket it might be helpful to make a sticky post giving instructions with a link to the issue tracker - if that already exists, then maybe don’t be shy about constantly linking to the post (I know other groups that do this and it’s helpful).
@nagrom, best way for submitting issue is to use the built in pre filled form, with usefull informations for devs: in webconf, there’s a big button for this in home page.
On the webconf main dashboard there is a big button labelled, “Report Issue”. That is the best way to report any issues. It creates a templated GitHub ticket, populated with system details which really helps in diagnosis.
If the webconf is not available (maybe due to the issue you are reporting) then reporting via the templates on the issue tracker and manually populating that data is also good.
We discuss issues here, sometimes to figure out if it is an actual issue but any bugs or feature requests should go into the issue tracker.
Hello,
I think I found a problem relating to midi-routing from/to a different chain.
At least I was trying “the cool way” from the wiki the other day and remembered that it worked!
Now I had in mind to create one or more midi-chains that outputs it’s input to an instrument-chain:
It should be no problem, right?
I tested now the same again with midi+audio-cahin like advice in the wiki, but also had no luck making that connection.
Could somebody test it, too?
Hi @Jojo_Action !
You don’t say what software version are you using neither your hardware setup. We need this info to have the context and reproduce the issue.
Should I suppose is latest Oran, right?
Thanks!
Sorry mate, yes, I just burned the latest image, update and reboot…it’s a v4 kit.
Hello again,
Sorry, I think my last replay wasn’t really helpful, missing information…
I finally hope to give enough information, to also get an answer to my question regarding midi-chains.
This is the situation again:
Jul 22 17:57:41 zynthian startx[908]: ERROR:zynthian_gui_midi_config.select_action: 'NoneType' object has no attribute 'aliases'This is the info from webconf:
HARDWARE
Raspberry Pi 4 Model B Rev 1.5
Audio: ZynADAC
Display: ZynScreen 3.5 (v1)
Wiring: MCP23017_ZynScreen
I2C: MCP23017@0x20
Profile: v4_studio
SYSTEM
Debian GNU/Linux 12 (bookworm)
Build Date: 2024-06-26
Memory: 7% (555M/7810M)
SD Card: 24% (13G/59G)
Temperature: 49.1ºC
Overclock: Medium
MIDI & UI
Tuning: 440 Hz
Master Channel: Off
Preload Presets: On
ZS3 (SubSnapShots): On
Power Save: 60 minutes
Audio Levels on Snapshots: On
SOFTWARE
zyncoder: oram (48972ce)
zynthian-ui: oram (4e060e8)
zynthian-sys: oram (5affa51)
zynthian-data: oram (e222e11)
zynthian-webconf: oram (f31699f)
The question(s):
Yep - that is a bug. Please use webconf’s “Report Issue” button to add a ticket to the issue tracker.
Others may not have noticed because it may be an unusual workflow. What are you trying to do?
I was just kind of exploring and had the idea to use a midi-chain, that get it’s MIDI notes from zynseq, to route it then to different instrument-chains…I didn’t have anything particular in mind, I think I was about to try to program a beat and wanted to layer some sounds. So I did try it similar to the “cool way” but only with the midi-chain, but the problem also seems to happen when you use the audio+midi-chain…
I have removed chains from the available destinations of MIDI output routing. It was not implemented (hence the error) and adding it is complex - not something to do just before a stable release. I question the need for it and encourage users to offer use-cases and workflows that might benefit from being able to route a MIDI chain to other chains.
You can change the MIDI channel of a chain to the same as others (or a playing sequence) to layer chains. (We don’t currently allow a single chain to accept multiple MIDI channels - only one channel or all channels. That could be an enhancement we consider.) You can still configure your physical MIDI input in Active Mode (aka State Mode) so to allow individual selection of chains. (That also needs admin menu “Active MIDI Channel” to be cleared.)
Hi @Jojo_Action, @riban and the rest!
I fixed the issue and restored the expected behavior. It was a regression, @riban !
Thanks
One use case coming to my mind - could also be accomplished without the feature of midi routing, keeping it all in the instrument chain:
Question that keep coming up to my mind:
I was once sitting in the train the other day for a long ride and wanted to have more control about sounds used for drums/beats or short percussive synth sounds with some effects on it. Those were set up in different instrument chains. And I didn’t get my head around it yet, but I somehow thought I could use the mentioned approach to get the sequence played in one pad of the zynseq somehow routed to different instruments but that would probably need some midi-effect per instrument-chain to filter the midi notes, I guess.
But now I can try it out if that works…
(EDIT) Yes, that workflow described in my last paragraph works with all the sounds that aren’t mapped like samplers loaded with drum machines:
Now it would be interesting to modulate the pitch of a note with the midi LFO but I haven’t found out to get that really working (without using patch age via vnc), but that’s another topic…
I couldn’t follow all of that. Maybe you could attach a snapshot that demonstrates this.
Raise a feature request with some detail of the actual plugins. This sounds like side-chaining that is (partially) implemented.
Hi @riban 
I am reporting here a potential Oram bug, for which I will also pull an issue notice on the GitHub tracker.
Context:
A bare-bones Rpi5 with latest Oram (as of July 23rd) is driven from an external computer through USB-C, in Gadget mode.
Issue:
If Multimbral is chosen in Admin/Midi IN as Midi reception mode, for the USB Host port, the setting is not saved in the current snapshot, and the Midi mode reverts to Active at next Oram startup.
I don’t know if the problem happens also on the V5 official kit: will check this out.
That looks like a bug that effects all MIDI inputs, not just USB-C (gadget). Report it and we will have a look.
OK 
I was testing and it seems to affect only USB-gadget port. I’m working on it.
BTW, i fixed the device list refreshing to work OK with USB-gadget.
Regards,