I'm using Gentoo and I'm interested using bristol - I found it via the gentoo-proaudio overlay and have now the latest version 0.10.6 (the tar-gz from SF) installed.
There were some problems that i had to fix first:
- The change of configure.ac and Makefile.in to use /usr/_share_/ ...
- Using jack bristol segfaulted while connecting the output ports to alsa_pcm:playback_*
I commented the code in file bristol/bristoljack.c out (it starts in line 287)
Now both programs (bristol and brighton) start. (I start them separated and not via startBristol to have better debugging possibilities)
And now the big Problem:
There is now audio-output - neither with jack nor with alsa (but i wouldn't want to use alsa even if it would work)
I connected all the ports with qjackctl and all other jack applications and synths are working fine!
This is how i start them:
$ brisol -audio jack -rate 48000 -count 512
and in a separate xterm:
$ brighton -b3
The connect and everything works fine, there is just no output
Do we need the "client/server" interface? Different Synths could be single processes - all managed by jack
Thanks in advance
It looks like you have two or three issue, no? The first one regards the autotools processes and rather than change the scripts I would have tried something like the '-prefix' option, that way you would not have to change the script for each release. If ou still do not get the paths you want then let me know so that I can change the auto files to give you what you want. This is for the moment not too important since you have the program up and running (see other problems below) however I don't really want to code '/usr/share' as a path into the files, preferring to stay with /usr/local for now. My issue is that whilst /usr/share may be preferrable for some sites it will not be for others and the autoconf scripts accept options to change the defaults.
You do not get Jack drivers compiled with the code - this is perhaps due to not finding the jack libraries - you should see this in the output from configure and perhaps you need to check the PKG config directories?
You now have the GUI and engine but no output. To be honest, you may have output but at such a low level that it cannot be heard. A previous post was fixed by moving the volume potentiometer on the left of the keyboards for the B3 - if bristol cannot find its memories then many values default to zero hence no signal, and that is distinctly possible if you have used the default directories. If that is not the case, ie, the volume controller is not set to zero then another possibility is that you need give bristol the option '-outgain 16' or even higher (start gradually, the B3 can pump out a big signal - some users have required 64 or 128). This is multiplier that is applied to the output signal and is independent for each synth. There is another option called '-gain' that applies globally.
Other issues you mention regard multiple synths with jack. At the moment the engine should be started just once, and every GUI you start will connect to the same engine over TCP port 5028 (this is also an option). The engine then works multi-timbrally however all the outputs from each synth are folded back onto the same stereo ports. I have an enhancement open to have each synch open its own jack ports, that will allow you to mix them all separately however there are several issues here since you could start two different B3 emulations and I am not certain that hack accepts the same name twice. That means I have to add even more code such that you can define the symbolic names of ports you want to appear in qjackctl. This is of course possible but it is quite a lot of code for reasons rather difficult to explain here.
You can start multiple engines - give them a separate TCP port ID (the -port option woould allow 5028 and 5029 or example as long as they are free), however you cannot give them different jack symbolic names yet, they would both want to use bristol and that would probably fail again. This also needs to change, and this section of code was recently updates such that the GUI and the engine at least used different ALSA seq identifiers so that you could distinguish between them - that was required since both might want midi input, one to control the engine from your keyboard and the other to control the GUI from a MIDI control surface.
Hope that helps. I will watch out for responses.
Thanks - Wow, that is support
It is solved - i just reinstalled it with the normal, unmodified paths and it worked! (The problem were the memory-paths, The jack-issue is still there)
> Using jack bristol segfaulted while connecting the output ports to alsa_pcm:playback_*
> I commented the code in file bristol/bristoljack.c out (it starts in line 287)
Maybe it would be better to use another build-system, such as CMake. I don't know you busy you are, maybe i can help you (i've written several projects with the CMake build system).
I am not certain I want to use CMake. Software release 0.10 is fairly recent and was the first to use GNU autotools and I think it should stay that way at least for the time being. On top of that I have absolutly no experience with CMake which means it would take a while to get it integrated, it would be a lot of work, and it would not really affect functionality so comes in as a non-productive development effort. Perhaps in the future or perhaps with your support....
Your problem with the jack drivers is strange - from my code (0.10.7) it looks like line 287 are the requests to link to the jack server, so commenting them out should not have worked. Can you send me a copy of the modified file or the diffs? Alternatively, the original code may have worked with the option '-jack' rather than '-audio jack'. There are differences in these, the -jack option sets diverse variables for the jack interface whilst the -audio only affects the audio interface and hence can fail if the MIDI interface is not correctly specified accordingly. Will see if I can reproduce it here since the error messages you are seeing do relate to ALSA audio library calls and not MIDI. Either way, what you are seeeing should not have happened - perhaps the '-audio jack' option does not clear the default (ALSA) setting although your changes should not have affected that.
One last note, you commented on the client/server interface talking about the GUI and engine, no? As explained, the same engine will drive all the emulations and the same GUI can actually open multiple windows as the same process to configure the different emulations. Unfortunately, even though the graphics library was architecture to support multiple windows there is currently no interface to start them, hence you have to use multiple GUI to the same engine. Work is being done to change this - introducing a pop-up menu interface to the library. That will be in 0.10.8 (current planning) and the multiple windows will be started from those menus in a later release. I also have plans to allow you to merge the GUI and engine into a single multithreaded process (probably at compile time) rather than separate ones. Both architectures have pros and cons, the reason I like the separation is that you can run the engine on one PC and the GUI on another, connnecting them with MIDI/TCP, that way it is feasable to prevent GUI performance haffecting or being affected by the audio emulation.
Okay, I just recognized the new version 0.10.7 (that was the 6th download so far)
The Problem with jack is still there, no matter whether I'm using -audio jack, -jack or both of them. I'm using jack 0.103.0.
I had some more looks at the code:
In line 208 you connect the Segmentation Fault signal to the normal "JackClose" function. i think thats perhaps not so wise ;)
This segfault is received (with jack 103) unless you delete/comment out line 307 in bristol/bristoljack.c. The function called is "jackPortStats". I tried to debug it with gdb:
Bristol segfaults, because of line 171, that prints the ports in a for-loop. If i comment it out, bristol segfaults in line 309, "jack_connect". I gave up :(
Ok, networking is a reason for the client/server interface, but that would give a high latency rate. Jack is able to transport audio over network, too
Idea: bristol stays a normal library without network support. You can use it by a C-API from every other program (a plugin for "lmms", for example, there are some plugin-api standards for linux). The network part becomes an extra program, that is using the bristol-library and exporting it's functions as we have it now (on port 5028). Brighton then can decide whether it should use the net-interface or the library directly.
That sounds like many work, but it would be fun for me to help and later it is much easier for other projects to use this great synthesizer!
Hope i'm not disturbing your project too much
Tomorrow i'm a bit busy, but i will soon start adapting the build-system to CMake.
I installed 0.103.0 as well, rebuilt the whole lot including bristol, and apart from some issues with the version of jackstart (which had to be recompiled and installed to be the write version) it worked.
A few pointers:
The call to jackPortStats() failed because the ports array has not been stuffed. When you comment that out then next call that uses this structure also fails - jack_connect(). The problem is before any of this happens since the jackPortStats is used to stuff the array of port names and types so that bristol can build some set of default IO.
In your first submit you explained that bristol was attempting to use the ALSA audio interface. This is what I do, per default, when no jack has been requested or is not compiled into the code.
How do you get bristol to build with the jack libraries? The correct way is for ./configure to find jack.pc in $PKG_CONFIG_PATH, however it could also be hacked into the configure and build scripts. The only problem with hacking it in is that if multiple versions are available then bristol will not compile with the same libraries as root may be using, for example. There are also issues here to ensure that the jackstart matches the version of the ilbraries, and then the executable paths have to match the library paths and all that.
Do you build bristol as a user and install as root, anything like that? Do you have multiple jack version installed? Did you install jack manually, since if so you should have got the correct jackd.pc file and then could have used the ./configure script to find everything.
Strange problem. Will get it sorted, but it is the famous issue where my installation works here and all your other apps work there.
I did take out the SIGSEG signalling.
Regarding the CMake stuff, if it works then you might end up having to maintain it for a while, I am not sure I can do that with time constraints and limited knowledge of CMake.
Did you resolve this issue? There are a few more changes to the next upload and how the Jack drivers work, they may affect this issue.
I'm really sorry that i didn't respond for a very long time ...
Indeed, Bristol works for me now, and it is really wonderful
The jack problem: there were no input 'jacks', because of a output-only configured jack server. this was why bristol crashed.
The other problems were solved in later versions, i cannot remember exactly.
Thanks a lot!
I am willing to look into a resolution to that - bristol does not really require input so if my request for input fails I could consider just filling a null (empty) buffer and passing it to the algorithms. A couple of the synths take an input as a sound source although it has not been extensively tested as 'usable'. I may open up an enhancement request to cater for this.
Anyway, am pleased it works now.