Running multiple engines through jack

Help
2009-04-21
2013-05-23
  • Nick Copeland
    Nick Copeland
    2009-04-21

    This was posted after an email with a user:

    I've just recently tried to run two simultaneous instances with Jack, but in Jack Control, only one Bristol engine is ever present, although multiple instances of Brighton do appear according to the number of synths running. However, this isn't useful for audio. Is there a way to run multiple instances at once?

    Response:

    Yes, this is possible. The way you are working is launching two GUI to the same engine and the engine still only uses stereo outputs - it runs two emulations in multitimbral/multichannel but folds the outputs back onto the same jack connections. I have a goal to let the same bristol engine actually register different Jack connections for each emulation but the truth is it is a way off yet and to be honest, for multicore CPU at least, this method will probably be preferable anyway as it gives you better process distribution than using a single engine - the engine is multithreaded however the audio is still generated from a single thread and hence would only use one core and then use it very, very heavily. If you start multiple engine then they will get distributed across multiple cores.

    To get this to work you need to use some other options to startBristol, the -port option and the -devname option. The default port is 5028, it is an arbitrary number and generally is free. You can use the -port option to use another value (this is the TCP socket ID used to connect brighton to bristol). The simplest one would be 5029. When using Jack as the interface then -devname is the token that will be registered with jackd. The default is 'bristol', so you could give 'bristol2' for the second one to prevent conflicts in the jack naming system:

    startBristol -b3 -jack -count 1024
    startBristol -mini -jack -count 1024 -port 5029 -devname bristol2

    The first line would use the default values of '-port 5028 -devname bristol'. The -count option is just to get bristol to register on my system with the jackd vanilla period size - yours is probably different already as this is a very high value for a realtime synth.

    There is one issue here, a bug regarding midi channel selection: you probably want to start the different engine on different midi channels to begin with, for example giving -channel 10 to the second request above. At the moment this fails which means you have to start both of them with the same default MIDI channel (1) and then move one of them using the GUI - press the midi channel UP button in the mini twice and it will then play independently. The B3 uses two channels, 1 for the upper manual and 2 for the lower manual, so the next synth should be put on midi channel 3 otherwise you will be playing them both mulitilayered from the same controller.

    I should open a bug on sourceforge for the midi channel option failure and allowing you to start the engines on different channels. It used to work and I think the bug is rather stupid (such as using the literal number rather than the 'ordinal' number) but still needs to be fixed. If you want this to be fixed quickly you could open a bug report on sourceforge - they annoy me enough to make me fix the issues being reported.

    Just gave the above a quick test here on my system and apart from the MIDI channel errata it works.

    A bug will be opened for the MIDI channel issue.

     
    • Nick Copeland
      Nick Copeland
      2009-04-22

      The MIDI channel selection failure is resolved so the commands below will now work. Note that the option '-devname' is incorrect, it is '-audiodev', this is parsed into an internal variable called devname however the correct syntax is:

      startBristol -b3 -jack -count 1024
      startBristol -mini -jack -count 1024 -port 5029 -audiodev bristol2 - channel 5

      If this audio device name is not given then the second invocation should actually attempt to register the name bristol and this gets declined. After that it should attempt to register with 'bristol_<port>' which should then work.

      This requires bristol-0.40.1 or higher.