Perhaps the device ID is different in bookworm. My launchpad mini mk3 changed its name and I had to add a new id alias to the driver.
Please, @tunagenes , copy the name you see in the device list for your APC
Regards
Perhaps, I think I know what to do, but I haven’t been able to get to a terminal on Oram Bookworm - when I try via WebConf I get 500 Internal Server Error. When I ssh by IP address I get No Route To Host, when I try ssh to zynthian.local I get a whole screen full of messages starting with Possible DNS spoofing or some such. I’ll try it on another system…
I have already captured the issue with webconf terminal.
I am able to ssh via IP.
Because the new image will have different ssh signature and your remote host (e.g. laptop) stores this signature for each host it connects to, you have to clear the signature from the remote host’s ssh config. My ssh client gave me a warning that included the command to remove the offending signature but if I don’t see that message then I either manually edit ~/.ssh/known_hosts or remove that file completely. The latter just means accepting authentication checks for each ssh server I connect to again.
[Edit] The command to clear the ssh reference is ssh-keygen -f "/home/user/.ssh/known_hosts" -R "hostname" (replace user and hostname).
1 Like
Hi @jofemodo - I asked this 4 days ago and I never saw an answer, I’d like to know which repo you’d like me to use for testing - zynthian-sys- chainman_bookworm or oram. The copy-paste below is what the https://os.zynthian.org/test/2024-02-20-zynthianos-bookworm-aarch64-oram-2402.zip image set and I don’t know if I should leave it like that or set zynthian-sys to oram like the other repos.
zyncoder: oram (9ea5d33)
zynthian-ui: oram (24a24e4)
zynthian-sys: chainman_bookworm (b653b15)
zynthian-data: oram (64c5f91)
zynthian-webconf: oram (a5442c1)
Hi @tunagenes!
The answer was probably delayed by effort to resolve differences between 32/64-bit. We made the decision (yesterday I think) to drop 32-bit support from Oram so I expect that these branches will be merged. (@jofemodo - can that be done today?)
So the answer to your question at this point in time is that you should use chainman_bookworm if you are using the 64-bit image and oram if you are using the 32-bit image. This is likely to change very soon.
2 Likes
Got it - Thank you!
Does this answer the question? This is from recently updated 64 bit Oram:
(venv) root@zynthian:~# amidi -l
Dir Device Name
IO hw:1,0,0 APC Key 25 mk2 APC Key 25 mk2 K
IO hw:1,0,1 APC Key 25 mk2 APC Key 25 mk2 C
IO hw:3,0 f_midi
(venv) root@zynthian:~#
I confirm these names as they are the same in my desktop (Pop_OS!/Ubuntu). I presume K is for Keybed and C for Control, or something like that.
It should be working now. If not, please, tell me the name you see in the MIDI device list from the zynthian-ui.
Regards,
This is the (ridiculous) effect of the change to the kernel. It is the device name “APC Key 25 mk2” plus a space plus the port / enpoint name “APC Key 25 mk2 C…” (probably “…Controller”) but this is truncated to 31 characters to fit the 32 byte buffer available for alsa names. I am amazed (and rather annoyed) that this issue has arisen and persists after two years. I haven’t found the right target for my angst yet and maybe by time I do, I will have clamed enough to provide a rational bug report / feature requests. (At the moment it would just be a rant about apparently daft decisions!)
The device driver for the controls would have the id “APC Key 25 mk2 IN 2” (if the keyboard was the first port and controls the second port). We now take the device name and append “IN”/“OUT” and the port number (1, 2, etc). The full URI actually includes “USB:x.y.z/” at the start which identifies the physical USB port to which it is attached. Ths is stripped for the device drivers and if Zynthian is configured to, it is ignored for ZS3 loading, i.e. the USB MIDI device can be plugged to any port.
3 Likes
I installed oram on one of my SD cards because I was asked to do some latency measurements after having raised a ticket regarding latency a while back.
After some initial hickups thinking the image was bad because nothing appeared on the touchscreen after booting, I heeded the advice of pointing my browser at the Zynthian anyway and performing an upgrade via webconf, which worked like a charm.
I must say I’m looking forward to the update. One thing I noticed is that adding and removing chains is lightning quick compared to how it was before.
But where has stage vs. multitimbral mode gone? I can’t find the setting, and the device seems to be in stage mode perpetually.
Unfortunately my latency measurements reveal that the latency is higher and varies more than in the stable release. But it’s early days yet.
The Stage vs. Multitimbral mode has changed significantly - it is now an individual setting on a per chain basis I think. If you search the forum for “Multitimbral” you’ll find quite a bit about it. I don’t know what’s the best topic for info, here’s one:
1 Like
Bold Press the chain and you find MIDI In.
Bold Press the Midi input whose behaviour you want to change.
And now you can turn on multitimbral.
I am not sure, but unlike tunagenes said, it’s not per chain on my device, but per input device.
Or at least it’s a option, that you don’t have to do it for all chains.
If you want to clone midi channels, you have to create a new Midi Chain (an empty one).
Here you see Midi Out as option. Scroll down and select all engines, you want to copy.
This is necessary, if you are on Stage Mode and want to play more than one engine at once.
In Multitimbral mode it is not neccessary, because you can layer the chains with the same MIDI channel.
3 Likes
Indeed the device mode (active channel / multitimbal) is per device, not per chain.
1 Like
Hi Zynthianers!,
I am giving a try to Oram, and have found some strange things.
First, after install on a fresh SD card of 64 GB, the system has not detected my configuration as you can see (graphic 1).
(graphic 2) shows the actual config.
Second, everything seems fine except that my 7 inches screen still does not work with any config tested.
Third, the most strange is that pianoteq has dissapeared of my choices. However, when I reinstall the ptq of 8.2.2 , at first instance, when reappears, it seems to unblock all the choices of pianos !!!
However I test it and always sounds the same.
I do a software update (really really long) and AGAIN pianoteq dissapears again. I do not find it in any subject.
The most strange of all is that meanwhile I have installed the version 8.2.2. (graphic 3), ZYNTHIAN shows as installed version 8.1.3 (graphic 4).
Any idea or suggestion?
P.S.: I am testing with Behringer UMC 204HD instead of 404HD (I have both), and though it seems to work fine, I was wondering if this may have any kind of participation in my misadventures…
Regards
Hi @erasmo !
Only official kits are detected. Custom setups must be configured by hand.
Have you updated the software after burning the image? This is the first thing you should do .
Regards
1 Like
Hi @jofemodo!,
Yes I updated the software on webconf after configuring all parameters of my setup.
It was a very long update.
After that, everything seems to work except pianoteq.
Regards,
Obtener BlueMail para Android
En 2 may 2024, en 0:47, Jofemodo via Zynthian Discourse <discourse@zynthian.org> escribió:
Hi guys!
I got Pianoteq over Oram, after deactivate all engines enabling only Pianoteq.
However, though I have installed v8.2.2, Zynthian engines still shows v8.1.3.
This happened after burning a new image on SD, and proceed to software update prior to install Pianoteq. I could appreciate that BEFORE install the Pianoteq and enter the serial number, the defect configuration was showing 8.1.3 instead of v7.
Strange anyhow.