I read that you should be able to run the engine and GUI:s on different hosts, but I have not found the way to specify the hostname/IP-address of the engine (I guess the GUI needs to know the engine's host).
How do i do it? Is it "hidden" into the syntax for "-port"? If so, what is the syntax?
This capability was always a part of the original design however it became a bit obfuscated in the need to make the program more accessible. The startBistol script does a bit of hunting around for the different programs, libraries, directories, and as a part of this automation (so that a user did not need to put lots of environment variables into their profile) the distributed process are not automated.
This is not actually the first request to have it put back in though. What happens in the libraries is that
1. the engine is started on a system with an audio interface, it opens a TCP socket and waits to accept() connections.
2. the GUI is started and it connects to that socket, now defaulting to localhost.
Both of these steps are buried in startBristol. To distribute then the script will have to be modified a bit so that:
a. it has an option to only start the engine
b. it correctly parses an option to only start the GUI and direct it to another host.
In short, it can be done but I would not advise this at the moment. There are a couple of other issues, for example, the GUI sometimes also wants to see the MIDI data (so that it can track keypresses and more importantly, so that you can have MIDI program changes and controller tracking - these are GUI based, not engine based) so if the GUI is on another system where the MIDI is not generated then these features are not going to be available.
I can open a couple of features requests though:
i. to make this accessible again and target it for the next release.
ii. to make the MIDI events distributed over the same TCP socket so that the engine can send MIDI events to the GUI or vice versa and make that available in some other release (as it is more work).
So, to make a long story very boring, the network distribution was done because I an a network engineer. This network distribution turned out to be a solution to a problem nobody has ever had, by which I mean there has not been any real demand for the capability.
Let me work on the first feature request to make it easier to access, after that, if it works and is useful, we can make it better with some more features.
Kind regards, nick
the path you outline sound great.
Meanwhile, would it somehow be possible to start just an engine (bristol) on the local machine.
The resaon is that I would like to start/stop different synths and sometime the first one started (the one that created the engine) I like to stop while having the others running.
At the moment is it not possible to just start the engine from startBristol - you either start the GUI and engine together, or you just start the GUI (and connect to the same engine). This is very similar:
startBristol -mini -jack
startBristol -b3 -engine
The first command (you can do this in different windows) will start a mini with Jack as the audio interface. The second will connect to the same engine but start a B3 organ emulator.
Now we are going to have a lot of fun here. You may get 'unexpected results' if you start and stop emulators time and time again. The fun is that I may have to get you to give me some debuging output from time to time if there are issues, or at least very good descriptions of what you are starting and stopping so that I can reproduce the issues.
Just to make you aware, if you start two of the same emulators, and then kill one, the cleanup routines may give the other emulator that is still running some problems. It should not happen and when it does I can fix it, it is loose buffer management. Just let me know.
Kind regards, nick.
I have recoded a small part of the startBristol script and the midi library, it now allows you to just start the engine, or the GUI, or both depending on what you want to do, and you can use an option '-host' for the GUI to tell it where to connect. The logic on the GUI and engine switches is now a bit awkward - you used to specify -engine meant 'do not start the engine' and so -gui is 'do not start the GUI'. That looks backwards now but will have to live with it for at least a while.
It will be in the next release. I can get you early code but I was going to wait until I had fixed the DX problem, something I expect to have done this weekend for early next week.
This sounds great!!!
Even though I am eager to test these new facilities I think your time is now better spent with fixing the additional problems. I have other things to do while waiting for an update :)
In about 15 mintues you will find a copy the URL below of an early 0.40.5 release. When the DX problem is solved I might roll all the fixes up into a release next week so I am happy you try them out. For the distributed stuff:
startBristol -gui -jack -count 128 -samplerate 48000 [whatever else you want the engine to have - alsa drivers, etc]
startBristol -engine -host host1:5028 -mini -gain 4
The GUI that you start on a host called host2 will connect to a bristol engine running on a host called host1.
Great, I will test this within a few hours :)
My first test was to create an engine and then connect to it from a brighton instance on the same host. It turned out fine, but I did not do any extensive testing in this setup.
Next test was to have the engine and the gui on different hosts. It started out nicely, GREAT!!!!, but then when I started to do more "advanced" operations it turned out that there is room for improvement :)
- having one gui started and then shutdown the gui, the engine terminated
- in various situations where I started and stopped gui instances, the engine came into
some mode(s) where it consumed closed to 100% of the CPU
- No midi connection showed up in the engine
- Midi connection showed up on the gui side. I connected a keyboard and when I pressed
the keys the corresponding keys on the GUI were pressed down too, but no audio came
out from the engine.
Please let me know about any more details you would need to know and I will fix it - as long as the info is provided my my current system.
Regarding the syntax of the command line:
Suggestion1: -server instead of -gui to indicate that you start in server mode
Suggestion2: no emulator specification (today starts B3 if I remember correctly) would
start in server mode. Since it is not bw compatible, I guess Suggestion1
would be better.
The room for improvement on more advanced operation is the fun stuff I was mentioning to you, its a part of bristol that has never been widely used so it will be deficient in some areas and, to be honest, buggy in others.
1. engine terminates with last emulator
This is true. I did once code an override however there were some large changes to the general init/exit routines to support jack and this went by the wayside. The issue is that if you use jack as an audio server, do you really want to use bristol then as a synth server in front of jack? There are good reasons why you wouldn't do this and Jack is where most audio work is on Linux. Let me review the issue and see when I can reimplement the feature as I did like it too. Do you use Jack or ALSA audio for bristol? ALSA is the default if you don't specify OSS or Jack.
2. Engine chews 100% CPU
I would probably need some more details of how you reproduce this. I don't doubt it happens, this kind of odd behaviour and crashes (seg faults) are going to be there until the code gets cleaned up.
3. No midi connection in engine.
Is this on one host or two? If you are using two hosts then the engine currently needs to be on the same host as the soundcard and midi controller. Anyway, having the ALSA midi port disappear on the engine host implies either bristol or its midithread has exit. Could be related to point 2.
4. Having -server option: will change this. I don't want to remove the default emulator, it lets people get started easily.
> 1. engine terminates with last emulator
First of all, I use Jack on the server side (bristol). I started the server with
sudo qjackctl &
and then started jack via qjackctl and once jack was running:
sudo startBristol -gui -jack
I am not sure I understand your point regarding not having a bristol server in a jack
context. In my view the brighton/bristol separation allows you to separate the gui from the
engine and what jack provides is an infrastructure that allows you to share the audio
resources between applications on the same host (with netjack multiple hosts).
I can very well see a scenario where you have 1 Audio Server host and multiple (N) Synth
Server hosts and some Client Controller host (where the GUI:s are). Jack controls the
audio device on the Audio Server, the Synth Servers hosts jack applications that will
route their audio streams to the Audio Server using netjack. The GUI:s on the Client
Controller connects to the synths on the Synth Servers to control the operation of the synths.
MIDI could be distributed in various ways in a setup like this, e.g. hardware, alsa, netjack,
My bottom line is that Jack does not provide any separation between synths' engine and GUI,
this is a feature of brighton/bristol. For other synths you could likely use VNC or similar but
since that is a general mechanism it will be hard to get as efficient (processing and
communication wise) as a dedicated connection.
> 2. Engine chews 100% CPU
I will try to find out some usage pattern that reproduces the situation during the day. As soon
as I have something I will let you know.
> 3. No midi connection in engine.
The thing is that no seq device shows up at all on the server side. I tried with various
command line options ( -midi ...) but no bristol midi device shows up (I use the ALSA-tab
in qjackctl to connect/disconnect) so I can not connect anything.
On the gui side the brighton midi device shows up (and as said I can connect there but
the midi events stops in the gui and is not forwarded to the server - inlin with what you
said I believe)
1. engine terminates with the last emulator.
Having bristol work with Jack makes a lot of sense. The question that kept coming up in my mind was why would you use a single multitbral bristol into jack. Remember, bristol collapses all of its emulations down onto a stereo output and runs its audio processing as a single rather heavyweight thread. The single stereo outputs is sensible in the context of bristol as a standalone engine in most cases but if it is mixed with Jack then there are lots of benefits to be gained from actually starting multiple bristol engines:
1.1 They all appear as separate devices in Jack and can be mixed accordingly
1.2 They all run as separate processes so it can distribute over multiple cores
1.3 It is a simplified architecture hence inherently more likely to work
You can still run multiple bristol engines, each with a GUI resident on different hosts on the network, and each engine connects into the same jack audio server.
Lars, don't get me wrong here, I write bristol, I am completely behind what you want to do and I want to get the multitimbral stuff cleaned up and working. Having both options is a good thing even if it does introduce complexity. At the same time, have you tried starting multiple bristol engines on the same Jack server system?
startBristol -jack -gui &
startBristol -jack -gui
They should start up with different TCP ports, they should appear in Jack with that TCP port ID (or you can even specify a name to connect with, its documented somewhere), and apart from point 3 below they should both appear in ALSA Seq.
I have some time this weekend to start up a few tests - one engine, multiple GUI, starting/stop emulators. I might be able to test multiple client hosts if I crank up my VMware too however I don't think that will be necessary. This is likely in itself to give me some coding work and if I cannot get the same issue with CPU then I will let you know and also think of some useful ways to go about debuging it on your system.
3. No Midi connection in engine
Ok, I get the same wierdness here now with 0.40.5, will get it resolved asap. I tested 0.40.4 and both bristol and brighton register with ALSA Seq so it is due to the current stuff I am working on - you have an early release of that code.
Yes, I can see the benefits of using multiple engines :). I will try it out.
The following scenario will get the server into 100% CPU load:
Two different hosts.
Start jack using "sudo qjackctl &" and then Start button i qjackctl
Start the server using "sudo start -gui -jack"
Connect bristol to system using qjackctl Connection->Audio tab
startBristol -engine -host 192.168.0.11 -mini &
startBristol -engine -host 192.168.0.11 -solina
Now everything works fine when I press keys on the mini or the solina.
If I try to close any of the gui windows (mini or solina) the server goes into chew CPU mode.
Nice one, I will reproduce this and get working on a fix. I will continue to work on the start/stop failures when using a single multitimbral engine. It was always supposed to work but I don't think many people ever dared to use it that much.
If you test multiple engines, try the -audiodev flag with Jack - this should be the name used to register the engine, it needs to be unique for Jack. If you don't use it then it should still work but will take a default alternative name which should use the emulator name, then the emulator name plus port number if you start multiple instances of the same emulator.
You can also specify the ports you want to use with the -port option, otherwise bristol will look for free ports scanning upwards from 5028. This method works for single systems however if you really want to distribute the apps then you probably want to define the port numbers a priori since you will have to pass them as a parameters on the client side with -host <ip:port>
When I have cleaned up a couple of the bugs this weekend I will try and give you a rundown of features I will try and code for you.
The following file will get you the bristol MIDI registration back on the server side. I have a separate piece of development work to get bristol to work on a system that neither ALSA nor OSS installed and there was a misplaced flag.
the patch you provided fixed the problem. Thank you very much.
I have left the -gui option as is - do not start the GUI. I have renamed/reworked the -T option as -server, it will direct the engine to stay operational even though all emulators have terminated so you can do
startBristol -gui -server
and on another system
startBristol -engine -host <engine host> -<emulator>
Additionally I am working on two other issues for you:
1. MIDI messages need to be redistributed
If you distribute bristol then it should really make sure that a midi message that is delivered to the engine gets passed to the GUI and vice versa. I have the code done for GUI to engine and am working on the engine to GUI.
2. The engine gets annoyed after a lot of connects/disconnects.
There are a few bugs that only really show up with server mode so I am going through this code. I have fix a couple of erroneous ID that cause the wrong emulators to be stopped out of the list of operational ones, caused internal ID to continually increment then run out, and I am now looking at another issue that seems to affect the 'dual' synths, the ones that use two emulators such as prophet-10 and B3.
Will let you know as soon as I have some code for you to test. I have written a script that automates start and stop of the GUI and want it to run for a few thousand iterations without damaging the engine before I decide it works or not.
I uploaded 0.40.5 which includes the fixes for distributed engine and GUI: it has a -gui and -server option, the server option prevents termination with last emulator and ran for nearly 800 reconnects.
This sounds great, thank you very much.
I am on a short trip and will be back home on Sunday. Then I will build and test this new release.
Am I to use one of "-server" and "-gui" or should both be used?
The two options, -gui and -server can be used together, apart, whatever. For example, the following would start a mini emulator with a GUI on the same host as the engine, then connect to that engine from another host and start a vox:
host1# startBristol -jack -mini -server
host2# startBristol -engine -host host1 -vox
You now have the GUI distributed over two hosts, one of which is also the engine. If you used the -GUI option on host2 then it would not start the minimoog emulator but you could still start the GUI on that host.
Will work on the MIDI event distribution and let you know when it is ready for testing.
kind regards, nick
I have now tested the new release and all went very well :). Thanks.
I am using set_rlimits to enable rt for the applications on my system (It does not support PAM), so I need somehow to make bristol start via set_rlimits (command: set_rlimits bristol ....). Is there
some (simple) way that I can tell startBristol to start bristol thru set_rlimits, without having to modify the startBristol script?
Do you see a need for brighton to run with rt scheduling as well?
Well, my advice at least, would be to put set_rlimits bristol in the boot up files, like putting it in /etc/rc.local.
Though maybe Nick has a better solution?
I do not really understand how and how that would help !?
Could you elaborate more on this idea?
if you open up /etc/rc.local right, you can type commands to be run when the system boots up.
So you could put in the command
so you wouldn't have to keep typing it everytime you wanted to run Bristol.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.