New testing image Bookworm Oram 64bits

I’ve observed this detail too. Very probably my MIDI controller is on channel 15, but it has always been there. I always worked in stage mode, so it didn’t matter then.

So, @pau - is this now working for you? The converter looks for zs3 names and uses them if they are available. In the version of Zynthian that you saved the snapshot, all zs3 were called “New ZS3”, hence why they are simiarly named by the converter. I believe this is working by design. Please describe any issues you are still having.

1 Like

You are right. This font is not clear enough

Regards,

But they are not empty, Pau! Why do you say they are empty? The “New ZS3” is just a generic name. We could improve this, of course, but the ZS3s are not empty.

Regards,

1 Like

Sorry if I have not been clear, it’s probably my mistake, so let me explain.

I use an external MIDI controller to send the Midi Program Changes. I have not changed its configuration, so I guess it’s in CH15. The expected behaviour IMHO should be that ZS3 subsnapshots saved in stage mode -which I can see thar are associated to CH0- should still be recallable using the same controller.

AFAICS now Midi Program Changes keep the midi channle, so the new ones I store are in CH15, but I cannot recall the ones in CH0 which was how they were stored before,

I suppose that this is my misunderstanding. They are there but are worthless for me as I cannot use them as I used to.

I don’t have enough knowledge to judge if Midi PCs should be different depending on the MIDI channel.

I hope this clarifies why I say they are not working: they are obviously there -sorry for the confusion- but I cannot use them -unless I reconfigure my controller to uyse channel 0.

Best
Pau

1 Like

So the real problem is you can’t recall the snapshots using Program Change like before, right?
Please, could you check that the imported ZS3s are right by recalling them using the UI? I will fix the Program Change issue, what i hope is quite easy, but i would like to know if the ZS3s “contents” have been imported correctly, that is the difficult part :wink:

Regards,

1 Like

Unfortunately the old ones are not recalled, but I can manuallly recall the new ones.

And another small glitch: when I bold press select on the snapshot to see the options, I cannot select or go back, there’s something wrong in that menu :disappointed_relieved:

Fatal Python error: Segmentation fault
Thread 0x0000007f85f9b4c0 (most recent call first):
File “/zynthian/zynthian-ui/zyncoder/zyncore.py”, line 42 in lib_zyncore_init
File “/zynthian/zynthian-ui/zyngui/zynthian_gui_config.py”, line 696 in

With up to date Oram and

Raspberry Pi 4 Model B Rev 1.2
Audio: RBPi Headphones
Display: PiScreen 3.5 (v1)
Wiring: DUMMIES
I2C: Not detected

Well, display is one of the infamous

http://www.lcdwiki.com/3.5inch_RPi_Display

it works with piscreen overlay (X is running, I can start the native instrument view -the one exported through VNC- or a console)
It just makes zynthian to crash for a call coming from zyncoder init. With an other display, there is no error.

Do you have encoders and buttons? It could be a pin conflict.

Regards

Do you mean you click on the imported ZS3s from list and they are not recalled?
But i just tested with your original snapshot and i can recall manually by selecting from the list.
It seems to be “repeated” ZS3s, but i suppose that you have a ZS3 per song, or something like that.

Sorry, i can’t reproduce this. It works perfectly for me. Could you send the steps to reproduce and the UI logs?

Thanks!

No I don’t. But everything works as expected with DSI display, HDMI+USB touch or even headless.
On Pi3B+ or Pi4B.

Funny fact is that with Oram, it is just a lttle bit better than with an up to date RaspiOs.

Despite the segmentation fault, some zynthian services/scripts are running and especially Xorg. After stoping zynthian service, I can launch “startx” and show the “native apps UI” on the display (but, except the patchage “task”, it is empty, because the snapshots are not loaded I guess).
Even touchscreen is responsible.

With RaspiOs, I can confirm that “it (mostly :innocent: ) works”: I see the bootlogs on the display and can start a session in console mode.
But when display manager is enabled, everything seems running (lxpanel, pcmanfm, Xorg …) but the display is just … dark ! Pfff

Hi @pau !

I just pushed some improvements to ZS3 import and management.
Now i can recall the ZS3s from your original snapshot using program change. Could you update and test again? Please, use the original snapshot from stable. If you saved with Oram, it’s broken because import was not working OK. You have to import the original one again.

Thanks for helping to debug this! We are close now :wink:

Regards

1 Like

Hi Fer.

I’ve updated to the latest version and I’m sorry to say that it does not work :sob: I can’t find a clear pattern, it’s certainly wierd.

What works?
-the number of subsnapshots is correct
-now PC messages are correctly sent using the same Midi controller, so you can recall subsnapshots

What does not work?
-presets are not properly restored. In most cases the engine is the right one, but only the last loaded preset is kept and it’s not replaced with the saved ones.
-in a wierd case and audio efffect is recalled

I attach another “stable” snapshot so that you can test it. All but one soundfont should belong to the standard ones. The one missing, a nice accordion sfz or sf2, would be nice to have addition :slight_smile:

Sorry for bothering you, if I had time I’d be willing to help in coding it!

Best
Pau

001-oriol-2023.zss (1.1 MB)

Will you please describe a step by step process to show the issue, i.e.

  • Do a thing - expect this behaviour - get this behaviour
  • Do another thing - expect this behaviour - get this behaviour

We don’t know what program change on what channel should be sent to see and hear what change in what chain. If you said something like, “I send program change 11 on channel 15 and expect chain 1 to change preset to Accordian but it does not change. I then send programe change 12 on channel 15 and expect chain 1 to change to Piano with fader at 50% - piano is selected but fader is at 100%” then we could try this out but we don’t know what is inside your brain!!! :wink:

1 Like

Hi @riban .

Excuse me but I thought that attaching the snapshot was enough. Llet me describe my snapshot and then the expected behaviour:

-chain 1: Pianoteq
-chain 2: ZynAddSubFX
-chain 3: sfizz
-chain 4: Dexed
-chain 14: setBfree

I use subsnapshots just to store presets, I don’t change any pan, effect, keyboard splits, gains, etc…

So I choose a preset for a chain, I store the subsnashot associated to a PC and that’s all.

The only thing I expect is that it is duly restored. As I only use it for that specific chain, the active one when you recall the snapshot, I don’t care about the rest. I only use it in stage mode, active mode now.

I only expect that each subsnapshot recalls the preset as descrbed in the attached document.I hope this helps.

Best
Pau

instruments-2023.pdf (25.0 KB)

1 Like

Hi @pau !!

Please, update and test now. I think i have it!! :wink:

Regards,

1 Like

Good news! Now subsnapshoits imported from the stable’s version snapshots are working as expected! Nice work.

But I have two small glitches to fix which affect the user interface, both in the subsnapshots menu:

  1. when you manually select a subsnapshot, the fitst line of the screen that describes the engine and preset is not updated with the loaded ZS3.
  2. When you enter to see the ZS3 details (bold press select) you are in a dead end: you cannot go back. as an additional information, if you use Program Changes, everythig works as expected, but in the UI you are trapped.

Thank you for your great work!

1 Like

Cool! Please report your issues to github issue tracker. We are concentating on Oram release and if it isn’t in the tracker, it may be missed.

1 Like

Do you mean from the control screen, right? Sorry, but i can’t reproduce the issue.
For me is works: the top bar is updated with the new preset when changing ZS3.

Sorry but it’s working for me too. I can’t reproduce the issue in V4 nor V5. I’m testing with your snapshot and also others. Could you send the UI logs when it get blocked? It should dump an exception.

Regards

1 Like

Please, @pau !

Could you verify your issues again and if they persist, send detailed description and steps for reproducing? Some UI logs would be really helpful, specially for the second issue.

Regards!