Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I built and ran Bristol on my system for the first time yesterday, Wooow, it looks and sounds great!!!!
After running and playing for a few minutes, the system got very slow and after a while a had to kill the bristol processes and then the system was back in its old shape again.
I am running the latest RT kernel (18.104.22.168-rt23).
I am guessing that the bristol processes requires some resource that "runs out", but I do not know what it could be. I am building up my system more or less from scratch so it is likely that I have made something "wrong" in my system setup.
In case you have had similar experiences or might have an idea of the cause/solution I would be most grateful to receive feedback.
I have not experienced this so we might need a bit of debugging to locate the cause of the issue.
Perhaps the best places to start would be to see the command line you use to start bristol and the debuging output:
Whatever it is, it will give me some idea of what is being requested. Secondly, the output from 'vmstat 10' in another terminal window would show changes in CPU, interupts, memory requirements over time whilst you are using the app. If it does look like odd things are happening we can then take a closer look at who is causing them.
kind regards, nick.
I discovered that the problem showed up when I tried to step up the Program (using the rightmost yellow button). I then tried to start with -load 2 and then I could step up thru the Programs and everything works fine. If I step down to PRG 1 or (possibly PRG 0) the synth stops to sound and I can not get it to sound again stepping up thru the Programs. In this case the CPU is not hogged as it was in the first case (without -load 2) when the CPU was used by close to 100% (using conky to show what goes on)
Any idea about what the problem with starting off with the default PRG might be?
Which emulator are you using though? What options do you give to startBristol - it must be more than just '-load 2' since that would start the B3. If you let me know which emulator it is I can try cycling through some memories and see what happens - it might be denormals which eat a lot of CPU at low load, it might be the DX operators giving continuous cycles with some parameters.
There should not be issues with starting off of the default program however if that program is damaged it might give you problems. Let me know if you use -mini, -prophet, -dx or something so I know which to look at.
kind regards, nick
I am so sorry, I thought I had written in my first post which emulator i used. It is the dx(7) emulator and I start with
startBristol -jack -dx
startBristol -jack -dx -load 2
One thing I failed to mention in case it is relevant is that I am using Jack2 (version 1.92) in case you know of any problems with running bristol under Jack2.
Ok, I can reproduce that. It's a bit late here to start coding so will look into it tomorrow, it may be denormals (floating point errata with very small numbers) or another anomaly with the DX code.
Let you know what I find.
I looked into this and did some buffer content limiting, prevented overrunning some of the frequency management lookups. There are still some issues which I think are related to denormals, ie, floating point processing for very small numbers. At the moment I am not going to clear this up, if I remove a few of the default memories (only some are affected) then the problem goes away.
I can give you guidelines on how to get this operational now on your system. A full fix is a long way off - I want to actually emulate the FM chips that Yamaha used rather than have FM emulating code. The bristol SID did this for the first time for the Commodore SID sound chip and I would like to do more of it. Its on the wishlist with no fixed dates.
please provide me with the guidelines.
The quickest way to do this would be the following:
Then restart. These were the only offending memories I could find. I will still look into the cause however actually emulating the chips is a pretty hot option, just need the time to get it done.
Ok, I remove these memories.
Looking forward for your chip emulation. I have got a DX7, which I bought in 1983 and it is still operational, so I can compare it with your emulation :)
BTW: is there some way to create "memories" from existing patches for DX7 (e.g. SYSEX load format) ?
The chip emulation is a long way off. At the moment I don't have details of how to parse DX memories and the only specs I can find are for the dx09/dx21/fb01 chip - these were used in arcade games so needed to be documented including memory formats. The bigger DX7 chips were proprietary and the specs were never published, that means it would have to be reverse engineered.
Now since Yamaha don't want to work with me on it then I don't really know a good way to ensure memory compatibility except for the dx9 family. The comparison will still make sense though. It is intended to be a lot closer than the current emulator which is a more generic 6 op FM algorithm. I am interested in some of the low level noise that made the chips actually quite warm and interesting, and then extracting that to be able to do a DX-1 type emulator with a couple of chips and a very clean signal.
the issue of 'unusably slow' should be fixed in that same 0.40.5 code - when you disconnect I did some incorrect FD handling causing a tight loop on the low priority MIDI thread. It should be fixed.
The only outstanding issue is distribution of MIDI messages. It works here from GUI to engine but there are a lot of changes to get engine to GUI to work so I thought it would be better to make that a separate release. The changes are only in the GUI event handling, the engine and MIDI library are done and and will not have to change: the messages do get distributed from the engine to the GUI but in the GUI I need a different hook from the MIDI library to the Brighton library.