Thanks for posting your directions for using distrobox....I too tried the same thing, but had problems getting it to install reliably. I had issues entering my username / password in the registration screen. Strange things like...cutting and pasting into the password field would result in 3x the amount of characters being pasted. Trying to type the password manually would result in 2-3x the characters duplicating in the password field....but perhaps I will try again, maybe it was something specific to my setup (Fedora 37)

On your other points, I heartily agree: Presonus please consider either a Flatpak or AppImage as your distribution method, it would reduce your support issues substantially as everyone would be getting a "known good working environment" bundled with the actual application.

Presonus please consider either a Flatpak or AppImage as your distribution method

Flatpak and AppImage are both sandboxed, right?
Studio One would not be able to load third-party plug-ins in this case.

julianwolff3 wrote

Presonus please consider either a Flatpak or AppImage as your distribution method

Flatpak and AppImage are both sandboxed, right?
Studio One would not be able to load third-party plug-ins in this case.

Good point. I'm not an expert in either (only a casual user of both). Out of the two I think Flatpak would have the greatest chance of being able to workaround the sandbox limitations. For reference, there is a program called Flatseal which provides a way to assign permissions to your flatpaks....the list of permissions you can provide is fairly extensive (ie. direct hardware support to specific devices, as well as assigning direct access to specific listed directories....).

I know its early days for Linux, but if flatpak doesn't pan out. A solid approach would be to base S1 around some LTS support distro. For my work we base our product on RHEL (and their clones like Alma, etc). The big benefit here is 10 year support cycle.....it makes developers job much easier when the underlying OS doesn't change.

julianwolff3 wroteFlatpak and AppImage are both sandboxed, right?
Studio One would not be able to load third-party plug-ins in this case.

Nope, it could. Bitwig Studio is also officially packaged as a flatpak. Flatpaks cannot access other flatpak's data but they have access to the home directory by default afaik.

bstin wroteI had issues entering my username / password in the registration screen. Strange things like...cutting and pasting into the password field would result in 3x the amount of characters being pasted. Trying to type the password manually would result in 2-3x the characters duplicating in the password field....

Things like that tend to happen to me when in battery saver mode. How likely is it to be a performance issue? (software freezing and therefore multiple keystrokes being detected)

Do you need wayland for this?

fruenpedersen wroteDo you need wayland for this?

Yep. Distrobox uses the host distribution's display server. You could try cage but I don´t imagine it being a pleasant experience.

Not at all

Just a note on flatpak and Bitwig studio. Flatpak works great with VSTs as long as they don't reference any special system libraries or tools (eg curl for update checks etc). This is not a big problem for native plugins but if you use yabridge to host Windows Dlls then it will not work because Wine really doesn't like to be sandboxed.

This is the main reason why Bitwig is still delivered as deb package as well as a flatpak.

RoMe wrotespecial system libraries or tools (eg curl for update checks etc). This is not a big problem for native plugins but if you use yabridge to host Windows Dlls then it will not work because Wine really doesn't like to be sandboxed.

This is the main reason why Bitwig is still delivered as deb package as well as a flatpak.

Good point!

In theory they could package wine + yabridge into the Flatpak....which may make some sense from the perspective of providing a "fully working DAW that can use Windows VSTs"

Official yabridge integration would be great... Also would speed up development of the project.

don't waste your time. This don't work.

unusable dont waste my time

Ok, I did it but now How I can use my interface through pipewire-jack?. I'm stuck here. Could you help me?. I'm on Fedora 39.

axelgonzalez4 wroteOk, I did it but now How I can use my interface through pipewire-jack?. I'm stuck here. Could you help me?. I'm on Fedora 39.

you need to check if the pipewire-jack-connection-kit package for fedora is installed, then add the user to the audio group and edit the etc/security/limits.conf file for RTTIME and edit the usr/share/pipewire/jack.conf file in accordance with the desired operating parameters interface

flathub certainly would work, but currently it would require the user to install another package called FlatSeal to let the user specify File System access for plugins. most linux users who use flathub packages at some point or another do end up installing FlatSeal to 'tweak' certain permissions/access etc.

However its perhaps not a good idea atm because for a commercial linux package it would make the installation require and extra step from the user. also being a commercial package im not sure it would be a good idea to rely on a third party packages to enable running of Studio One. obviously a simple install, enter user permissions is the way to go long term, however Flathub is certainly a viable option to be pursued long term if you want to be able to maintain a single install package thats independent of both the users Linux OS choice and the version of that Linux distro they are running

perhaps it could be useful for internal testing to asses the viability on other distros, though its probably at this early stage much better to just offer both a .deb and a .rpm package.

For the majority of Linux users who do Audio production catering for the lower common denominator of user skills/abilities regarding their knowledge of linux its inner workings by just providing both .deb and .rpm package would cater to 95% of all Linux distros likely to be used.

Currently Debian and Red Hat distros and their derivatives cater for around 98% all all user installations used for home/production work in most industries .

I'd actually be more interested at this stage in speaking to whomever is running you linux porting efforts to get some form of roadmap on whats currently happening and whats planned as well as what issues are currently be faced in getting this running to a state that is can be considered mainline.

Any Presonus dev's working on this please feel free to P.M or email me directly if appropriate to do so.

also Yabridge is definitely something worth having you dev team investigate as a future roadmap goal/target

julianwolff3 wrote

Presonus please consider either a Flatpak or AppImage as your distribution method

Flatpak and AppImage are both sandboxed, right?
Studio One would not be able to load third-party plug-ins in this case.

AppImage is not a sandbox system. I use various other AppImage applications that access plug-ins from other applications without any problems. An AppImage is actually just an archive file that contains all the required libraries. You can therefore also simply unpack AppImages.

This avoids the problem that the corresponding libraries are not available or are in the wrong version.

aronpetritz wroteOther, more cross-platform, packaging formats like flatpak might be better suited in the future

Agree. +1 for flatpak

aronpetritz wrote4. After receiving 'Container Setup Complete!' you should now be in the created container. From here you can move to wherever you downloaded the .deb installation file to (the home folder is shared so you will most likely need to cd to your Downloads folder:

Code: Select all

cd ~/Downloads

) and install the package using

Code: Select all

sudo apt install ./Studio\ One\ 6-x86_64.deb -y

I'm confused by the last message in this step. But as I understand it, this is normal. And should not affect the work of Studio One.

Code: Select all

Setting up libgtk-4-1:amd64 (4.12.3+ds-1ubuntu0.1) ...
Setting up libgtk-4-bin (4.12.3+ds-1ubuntu0.1) ...
Setting up libgtkmm-4.0-0:amd64 (4.10.0-4) ...
Setting up libgtk-4-media-gstreamer (4.12.3+ds-1ubuntu0.1) ...
Setting up studioone6 (6.5.1.96553) ...
Processing triggers for libc-bin (2.38-1ubuntu6) ...
N: Download is performed unsandboxed as root as file '/home/mikhail/Downloads/Studio One 6-x86_64.deb' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

aronpetritz wrote7. Almost there now! Let's update the desktop entry in the container. (You will need to install an editor like vim or nano within the container for this last step. I will use nano for this tutorial:

Code: Select all

sudo apt install nano -y

Open the desktop entry for Studio One

Code: Select all

sudo nano /usr/share/applications/com.presonus.studioapp.desktop

and edit the Exec path to the modified one

Code: Select all

/opt/PreSonus/studioone6/studioone %F

It seems I did everything right.

Code: Select all

❯ ls -la /opt/PreSonus/studioone6/studioone
-rwxr-xr-x. 1 root root 77402520 Oct 27 19:21 /opt/PreSonus/studioone6/studioone
❯ cat /usr/share/applications/com.presonus.studioapp.desktop
[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=Studio One 6
Comment=Digital Audio Workstation
Version=6.5.1.96553
Exec=/opt/PreSonus/studioone6/studioone %F
Icon=studioone
Categories=AudioVideo;Audio
MimeType=application/x.presonus-soundset;application/x.presonus-ioconfig+xml;application/x.presonus-instrument;application/x.presonus-trackpreset;application/x.presonus-audioloop;application/x.presonus-musicloop;application/x.presonus-keyswitches+xml;application/x.presonus-pitchlist+xml;application/x.presonus-license;application/x.presonus-quantize+xml;application/x.presonus-click+xml;application/x.presonus-pattern+xml;application/x.presonus-studioonemacro;application/x.presonus-studioonemacropage;application/x.presonus-capture-session;application/x.presonus-song;application/x.presonus-songtemplate;application/x.presonus-project;application/x.presonus-projecttemplate;application/x.presonus-show;application/x.presonus-showtemplate;application/x.ccl-preset;application/x.ccl-multipreset;application/x.ccl-install-package;application/x.ccl-colorscheme+xml;application/x.ccl-colorpalette+json;application/x.ccl-keyscheme+xml;application/x-kristal-project;audio/vnd.presonus.multitrack;application/vnd.bitwig.dawproject;

aronpetritz wrote8. NOW you can export the entry out of your container and have Studio One run at effectively native speeds on any distribution:

Code: Select all

distrobox-export --app 'Studio One 6'

So why am I getting this error message?

Code: Select all

❯ distrobox-export --app 'Studio One 6'
xargs: unmatched single quote; by default quotes are special to xargs unless you use the -0 option
Error: cannot find any desktop files.
Error: trying to export a non-installed application.

Anyway, I can launch Studio One so

Code: Select all

❯ /opt/PreSonus/studioone6/studioone
Selected graphics device: AMD Radeon RX 7900 XTX (RADV GFX1100)
### Warning: Module could not be loaded: /opt/PreSonus/studioone6/Plugins/videoengine.so: undefined symbol: _ZN5Video11VideoEngine14createInstanceERKN4Core8UIDBytesEPv
### Warning: UCNET:Enabled UDP multicast on official port 47809 (1 sockets)
### Warning: UCNET:Local UDP port bound to 36387 (3 sockets)
### Warning: UCNET:Adding server via UDP discovery 192.168.31.151 : tcp 46217 udp 48360 (alive event)
### Warning: UCNET:Server "Plug-in Scanner" (id = "{87573A39-069B-4694-A7E8-518BA1F9007C}.524521") resolved at host "192.168.31.151", tcp 46217 udp 48360
### Warning: UCNET:Resolving hostname localhost...
### Warning: UCNET:Connecting to localhost...
### Warning: UID conflict on class registration: Vertigo64 (AudioSynth VST2) => used by: Vertigo (AudioSynth VST3/Synth)
### Warning: UID conflict on class registration: Discovery64 (AudioSynth VST2) => used by: Discovery (AudioSynth VST3/Synth)
log path:'/home/mikhail/Desktop/Hive.log'
checking deskTopFile at: /home/mikhail/Desktop/Hive.log
DANGER: makeAutomatable implicitly sets the revision of parameter Rate of module VLFO to 0 but it was 3500 before!!!. See FRAME-2049 for details.
DANGER: makeAutomatable implicitly sets the revision of parameter Rate of module LFO1 to 0 but it was 3500 before!!!. See FRAME-2049 for details.
DANGER: makeAutomatable implicitly sets the revision of parameter Rate of module LFO2 to 0 but it was 3500 before!!!. See FRAME-2049 for details.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
### Warning: Unsupported sample format: 32
### Warning: Audio Device could not be startedWarning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
### Warning: [UserProfileManager] Signed in to Firestore
Warning: pthread_setschedparam failed with error 1
### Warning: UCNET:Started listening on TCP port 37751 (3 sockets)
### Warning: UCNET:Removing server via UDP discovery 192.168.31.151 : tcp 46217 udp 48360 (leave event)
### Warning: UCNET:Server "Plug-in Scanner" removed.
### Warning: UCNET:Server "Studio One/6.5.1.96553 Linux x64" registration reply received.

But Studio One does not see JACK audio server (actually I use Pipewire but Pipewire should emulate well JACK I am checked it with Bitwig Studio. Such configuration worked there...)

Code: Select all

connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
jackd 0.126.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details


JACK is running in realtime mode, but you are not allowed to use realtime scheduling.
Please check your /etc/security/limits.conf for the following line
and correct/add it if necessary:

  @audio          -       rtprio          99

After applying these changes, please re-login in order for them to take effect.

You don't appear to have a sane system configuration. It is very likely that you
encounter xruns. Please apply all the above mentioned changes and start jack again!
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
attempt to connect to server failed
Gtk-Message: 12:51:39.980: GtkDialog mapped without a transient parent. This is discouraged.

I am hear about making changes in

Code: Select all

/etc/security/limits.conf

But for me unclear where I should make this changes in container or on the host? On both environments this file are absent.

When I select ALSA I has another one warning message:

Code: Select all

Warning: pthread_create failed with error 1. Trying again with PTHREAD_INHERIT_SCHED.
### Warning: Unsupported sample format: 32
### Warning: Audio Device could not be started

And I don't have sound on any ALSA devices on my machine.

My distro is Fedora Rawhide.

There’s a good chance your issues are related to running rawhide. I wouldn’t recommend having rawhide if you intend any serious work to be done day to day. While it may run well atm it’s the equivalent of running Ubuntu unstable.
Aka it’s the actual public dev branch fedora use for testing things and stuff becomes broken on a daily/weekly basis.

Fwiw regular fedora is still generally running pretty blending edge in terms of package version and I’m most cases package versions are slightly ahead of standard Ubuntu ( and Ubuntu is based on Debian unstable, though debians slower dev cycle makes that likely a non issue in comparison)

Unfortunately unless you use snapshots changing back from rawhide to standard likely would need a reinstall.

Can I ask why you even use rawhide? It’s full of debug enabled options in the builds, normal fedora would actually run faster and more stable