Actually a x/y grid or matrix sounds like a really good solution!
Yup, connection grid/matrix scales worlds better than the initially cute wire graphics. It also has some hope of being usable with couple of encoders.
2 Likes
The table can grow rather rapidly. ZynRouter adds (many) outputs for each engine. Trying to draw this on paper quickly becomes unwieldy. It may work on the screen but there might be much scrolling which could be confusing.
Maybe Zynthian could become aware of external routing and save this so we could use GUI tools as required (or any other routing method) and Zynthian understands and recalls this routing
Iâm still fixating on bluetooth, and guiâs etc.
A little reading on a forum discussing Yamaha seqtrack I learned that its dynamic interaction with the hardware is by Sysex possibly over bluetooth midi.
In your opinion would it be possible that the interface vnc has with zynthian would be less consumptive of system resources (affecting performance of Zynthian) over bluetooth Midi?
Possibly even an app like touchOSC(mimic of the gui?) could do the guiâs heavy lifting?
Or perhaps a dedicated app that would integrate more intimately with zynthian and host the GUI?
I guess an alternate question would beâŚIs the poor performance Iâve heard about of the native gui of a particular engine a result of bandwidth issue or a system resource problem or both?
Its probably pretty clear I donât know what Im talking about, but at a very low level, my apologies.
I just think the ability to access the native guiâs and have good performance with the zynthian would be yoooog.
I donât know if youâll like this idea, but I have had some problems with Balena Etcher writing bad images, even when they successfully verified running on my Windows 10, Lenovo ThinkPad W520.
I âsolvedâ the problem by switching to Raspberry Pi Imager.
Edit: and I just noticed that I replied to a post from 2020âŚ
2 Likes
The resources used by the GUI are often animations, e.g. Surge has wonderful graphics showing the progress of the envelope generators. (Such a wonderful presentation of info that is obvious in hindsight but took dozens of years to appear on machines!) These kinds of things eat up CPU and it is particularly annoying when the GUI is not even being used. Basically, any extra CPU or RAM usage or disc access is undesirable on a resource constrained system like the Raspberry Pi used in Zynthian. (I think this is undesirable everywhere but programmers get used to having (apparently) limitless resources to use and abuse.) So we always recommend disabling VNC for production / live performance to avoid a reduction of available resources that could better be utilised by the far more important - delivery of audio to the audience.
BLE MIDI is on its way to Zynthian. We should see it in the next release, Oram. We had a working PoC but I think that may have broken in some recent changes. It is on my list to resolve. I hope to have BLE MIDI fully working by the time we release Oram.
SysEx has largely been ignored, or at least side-lined in Zynthian. We know it can be useful but until recently we have not needed it to work and so have filtered it out. @jofemodo has done some work recently to enable its use in some workflows. (I havenât had time to look at that so canât comment on it.) SysEx can be challenging to manage. It has undefined length and is extensible for use by different manufacturers in different ways. of course the low-level protocol is simple and well understood but providing high-level context around sysex can be tricky. It is also a data bandwidth hog with messages streaming continuously with often long message lengths. (This can break some hardware device handling of MIDI, e.g. some cheap USB MIDI dongles have small buffers that are exhausted by almost any sysex message but work fine with the shorter MIDI commands.)
BLE MIDI + SysEx is a challenge because of the delivery mechanims involved. MIDI is a send-and-pray protocol. It has no handshaking. The messages are sent from one device and it is hoped they arrive at the other end. BLE MIDI has a similar delievery approach. This is important for latency and jitter. You want a message to be sent and delivered once with minimum delay and without the latency and jitter that protocols like TCP/IP introduce with their clever validation of delivery and order. Indeed initially, realtime messages like SysEx were excluded from the BLE MIDI protocol but have now been added. I believe there remains the caveate that realtime messages (like any BLE MESSAGE) is not guaranteed to be delivered hence there is the capacity of data corruption in transit.
So SysEx over BLE MIDI may be availble soon (maybe in Oram). But does this provide what you requested? Maybe???
I am sceptical that someone will find time to write code or integrate existing apps into Zynthian to control devices like the seqtrack in the near future but the tools to do so may be available soon to support the intrepid developer. 
1 Like
Hi Leonard,
thanx for your idea.
My post was from 2020.
Now I can write my images without problems, but I donât know why.
Some probs come and go âŚ
Regards
Micki
Gesendet mit der Telekom Mail App
-----Original-Nachricht-----
Von: Leonard Fischer via Zynthian Discourse <discourse@zynthian.org>
Betreff: [Zynthian Discourse] [Using Zynthian] Receive SysEx-Data
Datum: 02.03.2024, 06:03 Uhr
An: <norbert.schreiber@t-online.de>
|
- |
| tunagenes
March 2 |
- | - |
Micki:
But after writing and verifying this with Etcher I had a checksum-error.
I donât know if youâll like this idea, but I have had some problems with Balena Etcher writing bad images, even when they successfully verified running on my Windows 10, Lenovo ThinkPad W520.
I âsolvedâ the problem by switching to Raspberry Pi Imager.
I would like to add that SysEx is currently being used in several controller drivers, like the different launchpads. Also, there is a PoC âSysEx senderâ, that allow sending SysEx files to selected devices.
What is not currently supported is receiving SysEx data. We have plans to implement a âSysEx receiverâ, so you could receive SysEx files.
Regarding using SysEx for controlling zynthian UI, itâs not in the list and probably it wonât be. There are much better options for implementing a remote API.
All the best,
1 Like
Also be aware that the version of ttyMIDI we use for processing the DIN-5 connections does not support sysex. (We could modify it if necessary but as it stands - no sysex.) ttyMIDI also converts note-on with zero velocity to explicit note-off (with velocity 64) and converts running status messages to full MIDI commands. This is all to simplify downstream code but is not necessary in Zynthian (or any other JACK based system) so there are many improvments that could be applied.
1 Like