Yes I realize using the 3.5mm audio jack on the Raspberry PI 4 will give very low quality audio. But good enough to just test out the software temporarily.
One additional feature I have realized I’d want is that if I have the TASCAM model 12 mixer plugged in to the Zynthian v5 as a soundcard with USB, but then I set the Tascam to storage mode, (basically acting as a micro sd card reader) then I’d like the storage volume it exposes to the Zynthian v5 be shared on my LAN with Samba. Can I do that?
That way, I wouldn’t need to unplug it and replug to my laptop to retrieve recordings or do file management on the Tascam. I realize going over the network is going to be slower but it probably won’t be the bottleneck for me since I am almost always transferring over the network on the destination end anyway.
This isn’t just a feature specific to the Tascam model 12 but is applicable to a lot of external gear people might want to hook up. My thought is that shares like this would be set up in the web interface?
There are some significant challenges to doing this.
First, Zynthian uses JACK as its audio server which depends upon having a soundcard for clocking, etc. If you disconnect your soundcard, e.g. change it to mass storage then JACK will be upset and I think it may not recover well when switched back, i.e. it may require a restart. In theory that should be resolvable but it is not a use case that we have considered because most users leave their soundcard connected throughout the life of the Zynthian. (It is a core element!)
If you change to mass storage then Zynthian should mount the device and make it available for recording and playing back audio / MIDI but we do not currently expose any storage directly to the network. We do expose recordings and configuration via the webconf for individual download / upload. This is curated so only some folders and files are exposed. Some extra code would be needed to expose attached storage as a network device. It is possible but not necessarily on our roadmap. (We try to avoid considering Zynthian as a computer and make it as much like an instrument or audio processor as we can.)
If it freaks out or crashes when an external USB audio device gets disconnected, that’d be a rather nasty bug because it is in the nature of external USB devices to get disconnected sometimes.
Seems like making the web interface able to add or remove additional folders for network sharing would be really useful though and not just for this.
This is JACK though. For all the proponents of it as a low latency audio server, it’s expecting a soundcard never to go away and is pretty rubbish in any other role.
Using pipewire can solve this, but only when the zynth team move to a newer Debian and are able to dedicate some time to switching over to it as a server.
If the USB-audio device is un-plugged while running zynthian-ui, zynthian-ui will crash because jackd will crash, This can’t be in other way. You are removing one of the key parts of the system, so the system can’t work without it and will fail. The question is how this fail is managed and if it could be recovered automatically when the audio device is plugged again.
I don’t think it’s so difficult to manage. Jackd is running as a systemd service and it will try to restart after a fail. Same for the zynthian-ui itself. So the current scheme is valid and indeed it should “work”. I mean, when you unplug the USB-audio interface, you should get the Zynthian error screen, that should try to restart the UI every few seconds. When the USB-audio interface is plugged again, jackd should be restarted automatically and so zynthian-UI. If this is not happening like this, we should fix it because this is the intended behaviour. Going forward is not planned, but this “gracefully failing with error screen + auto-recover when available again” should work.
Regarding “using zynthian as a file server for external storage”, it’s not in the roadmap and i doubt it’s going to be, but in the other hand, i must say it already work with the audio captured in external USB storage. I mean, using webconf tool you can access the audio captures in an external USB-storage.
OK that helps some but actually sharing it on the network would be better for a couple reasons:
File operations can be easily automated with scripting
What I actually do currently, when I pull audio recordings off the Tascam, is connect the Tascam to my laptop with a male USB-A to male USB-B cable, drag all the WAVs into foobar2000, tell foobar2000 to convert them to FLAC and set a folder on my NAS as the destination for the converted files. That way I’m not needing to download a copy, convert them, delete the originals and move the converted files to my NAS in four separate steps. Instead, it’s just one step of WAVs on the Tascam to FLACs on my NAS. The web interface can’t do that but sharing the files over the network could.
Well, this kind of customization would require some scripting and system adjustment from your side
If you do a nice work, we could consider to integrate it into the main distro.
OK, I might send a PR sometime for adding and removing custom network shares from the web interface. But in the meantime, I’ll just dig out the cable each time.
Looking forward to trying the “external gear” feature soon when I have time to figure out how to get my device onto using the test branch, or when it gets into the master branch, whichever comes first.
I’d like to suggest perhaps reconsidering that perspective at least a little, because SBCs aren’t as cheap as they used to be and the economy in general isn’t what it used to be so some lower income people might not have the luxury of totally dedicating the only Raspberry PI device they can get their hands on to just being full time for music only like that. Where someone could also get general computer functions at no additional cost to them and very little additional development, seems like it should be done.
I guess somebody who really wants to do other stuff can swap out a second micro SD card for that, but that’s still a pain for them to deal with.
In WebConf it’s ‘easy as pie’ - from the “SOFTWARE” menu at the top, select “Repositories”,
click the “Advanced view” and unclick “Stable”,
then select testing from all the pullown menus,
reboot (Twice if you’re a little stitous)
I’m sure that there are some situations where you’d only want to change a particular repo but this has sufficed for me so far…
Woupsy,
I’ve made that with my V4 and now y have the error screen (exit:1 and IP) but… no access to WebConf anymore, neither by wifi or ethernet
…
crap.
It doesn’t seem too.
Two hours of downloading a new stable version should (and I don’t remember how much time to engrave it).
The sad thing is that I wanted to buy a new Sd card to have a backup… I was silly to make the change before having it. Worst, before even make the backup file.
That was something I noticed about obtaining the Zynthian OS … the download is really slow. If I’m actively using Zynthian then I’d be willing to help seed a torrent to get the download to people faster.
Agreed, but perhaps on the good side, if you haven’t rewritten the original SD card, even if it won’t boot Zynthian, your customization files are still there and could be read from a PC and then transferred to a new card.
I don’t know if I made clear that I meant that if the files were shared over the network then it becomes possible to script file management from the client. I didn’t mean in Zynthian.
Is testing broken? Could you determine if is it the ui or webconf?
The logs would help me for blind-fixing the issue. I’m traveling with van and family, but have my laptop.
