Copy jamulus.ini from Windows unto Linux ?

[pcar75]

Bonjour,
My tower pc is now equipped with a bootable Ubuntu 22.04 LTS drive and almost all audio is working properly,
Can I copy the Windows' Jamulus.ini over to the Ubuntu one ?
If not, can I at least edit the Ubuntu jamulus.ini to add the <stored ... information from the Windows one ?

Or better yet , since I can read/write my Windows NTFS data hard disk files when booted in Ubuntu, could I use one single jamulus.ini (and jamulusserver.ini) file for both Windows and Ubuntu Jamulus ?

Thanks in advance.

[ann0see]

Hi @pcar75

Thanks for asking. I don't think anyone asked that before, and it isn't officially supported, but since the code is mostly the same for all platforms besides the audio API, you might be able to do some edits and get it to work.

To avoid any misunderstandings: what's your end goal (bigger goal)? Why do you want both OS to share their ini files? You can just set both up the same way and copy mixer levels if needed. Syncing might be a big hassle.

[pcar75]

@ann0see : Currently, I mostly use Windows , even for listening to Jamulus sessions over the world, but I boot to Ubuntu for participating in sessions, as I've found it shaves Overall Delay ms (sometimes substantially). Having the same jamulus.ini would allow me to keep the same settings for session users (including those muted) and some other info (ex. <ipaddress... ) without the hassle of copying/editing those everytime I change OS (i.e. no need for syncing).

My tower pc = i7-6700 @3.4MHz, 16 GB RAM, Windows 10 & all programs on SSD , Ubuntu & all programs on another SSD , all data on fast 1 TB hard disk in Windows NTFS.

[ann0see]

Ok. Understood. I'm doing something comparable, but just set up everything up on the fly.

[hoffie]

I'd say there are good chances for all of this to work. I'd just try it. From a quick glance I don't see anything which would "break".

If you mainly care about the stored fader levels, then I'd suggest using the import/export function for that, which is officially supported.

[pcar75]

@hoffie OOooops ! Sorry, I had missed that part of your answer before ! So, the import/export could be used to transfer the <stored... section from one jamulus.ini to another : only this section (i.e. not the <ipaddress... section for example) ?

[rdica]

@pcar75 One thing that won't work is the audio device choice, ie;

<auddev_base64>SmFjaw==</auddev_base64> This is Jack on Linux.

<auddev_base64>U3lzdGVtIERlZmF1bHQgSW4vT3V0IERldmljZXM=</auddev_base64> This is System Default In/Out Devices on Mac.

[pcar75]

@rdica Indeed, thanks.
I will test whether overwriting the <stored... section from one jamulus.ini to the other works and then find a way to automate this syncing on both OS.

[pcar75]

Or write a script that swaps an <auddv... entry in one environment for another ... using the same jamulus.ini file :-)

[pcar75]

To maintainers / developers :

Is there a way to comment certain *.ini lines , so for example a simple script or batch cmd could toggle the comments to actionable depending on OS or even computing platform ?
Example :
#Windows <auddev_base64>QkVIUklOR0VSIFVTQiBBVURJTw==</auddev_base64>
#Ubuntu <auddev_base64>SmFjaw==</auddev_base64>
So uncomment one depending under which OS/platform Jamulus is operated ?
#Windows <auddev_base64>QkVIUklOR0VSIFVTQiBBVURJTw==</auddev_base64>
<auddev_base64>SmFjaw==</auddev_base64>

Alternatively, could OS/platform be specified in those elements that are not shareable ?
Example :
<auddevWin_base64>QkVIUklOR0VSIFVTQiBBVURJTw==</auddevWin_base64>
<auddevUbuntu_base64>SmFjaw==</auddevUbuntu_base64>

Would this make a good feature request ?

Thanks in advance.

[pljones]

The current implementation overwrites the file each time, based on the values it wants written out. So you'd lose anything.

[rdica]

The overwrite is at process exit, not startup, correct?

[pljones]

Yes - so you could keep a file with comments in but using it would mean you'd lose the comments.

[ghost]

I suppose one could keep a copy with the comments.
What about making the file have read only permissions for Jamulus?

[pljones]

I think start up checks the file can be written to and rejects it as unsuitable if not. I could be wrong there.

[ghost]

Maybe the script parser in Jamulus can automatically ignore stuff that makes an error. This way, if something is platform specific or foo::specific or broken it will work/notwork depending on circumstance.
If this were done, the parser would have to provide an optional file that contains a line by line configuration status (a simple Y_ or N_ line prefix).

[pljones]

It uses the Qt built in XML parser. Bad XML will not work.

[pcar75]

@pljones Do you mean a statement or a section will be ignored, or that the whole file will be rejected ?

[pljones]

I mean that if the XML parser can't read the file as valid XML, it will be rejected, as far as I know. There's a single "Read XML file" command. Once it's read, it's processed in memory. It's built in memory before being written as a single XML object.

[pcar75]

For the record, I found some related discussion elements in the old SourceForge.net Discussion
https://sourceforge.net/p/llcon/discussion/ (search jamulus.ini).

I still think the best solution would be if Jamulus (client) could share one jamulus.ini file, acting upon that which is deemed shareable vs non-shareable ; but there are many cases that would orient the solution.
I have not thought further about shareable jamulusserver.ini but there are probably user cases there as well.

Currently, short of developping fonctionnality for doing this outside of Jamulus, I believe the best/least problematic avenue would be to enhance it's Import/Export function (alluded to by @hoffie above) to add the <ipaddress... entries. The idea being to facilitate usage from one configuration to another by sharing what is otherwise laborious to recreate with entry facilities.

Thanks for any and all comments.

[pcar75]

(...) to enhance it's Import/Export function (alluded to by @hoffie above) to add the <ipaddress... entries. The idea being to facilitate usage from one configuration to another by sharing what is otherwise laborious to recreate with entry facilities.

While it's is not fully 'specified' , may I open an 'Issue' under the label 'Specified feature' ?

[ann0see]

Yes.

[pcar75]

While this is a far cry from a "universal" jamulus.ini, I've nonetheless created minimal feature request.
Ref : Issues/ Feature Request : Enhance Import/Export. #2831

[henkdegroot]

Seems a bit related to #2626 , sounds like that suggested improvement could help making this work.