The pro-52 unison mode causes xruns when a key is pressed.
This is likely to be related to the heavy filter activity when the voices start. Have you tried with -lwf?
Another case is when you have speedstep active however this tends to cause jack 'zombified' messages. You can see speedstep from 'cat /proc/cpuinfo':
% grep MHz /proc/cpuinfo
cpu MHz : 800.000
cpu MHz : 800.000
If the value reported here is not your native clockspeed then stepping is probably in operation. I actualyl doubt if this is your issue but it is worth a check. The -lwf option is a big difference in CPU requirements for a similar tradeoff in filter warmth.
I have a plan to do a couple of optimisations on the filters but that work is a little way off.
Implemening bandwidth limited oscillators to reduce antialiasing will likely make this situation worse as it will need even more CPU at the higher frequencies.
kind regards, nick.
Hm, yeah, the -lwf option does stop me getting xruns when doing glissandos/using unison mode.
I also checked /proc/cpuinfo and there is no speedstepping.
Out of interest, what sort of filters are used for this emulation?
The filters are called Huovilainen. a 'non-linear moog ladder filter' implementation. They have already been optimised once but CPU requirements can be reduced further as they make heavy use of tanh() to limit the filter signal levels getting excessive. I have no idea when I will get around to that piece of work so for now there are also the LWF as an option.
Another of the optimisation of the filter was to introduce a bit of noise to prevent denormals (which did happen in the early releases). Is it one specific memory that does this in unison or all of them? I could check to see if it is related to denormals for any of the processing. It's another possiblity.
Unison mode on both the pro-52 and the obx cause xruns. I'm beginning to suspect it may be the filters, along with the amount of voices the emulators are trying to sound at the same time. FWIW, I don't experience this with mono mode on the polysix, most likely because it only uses 6 voices per default?
Andrew - that was damn astute.
The Polysix sticks to it's capabilities. The OB-X and Pro52 don't - they generate 32 voices and request access to all of them. Interestingly, well, for me anyway, is that the OB-Xa, Jupiter, Bitone emulators do restrict their voices as per the original since I have to do that to get the correct all/split/layer capabilities. None of the synths that were originally monophonic do that, ie, the mono synths all take the default number of voices, they just don't have the Unison feature.
What is your take? Should I do a default restriction according to the original that can be overridden? (see -emulate below).
Perhaps not: you now have another fix/workaround which is to use the -voices option. The synth will always start 32 voices and then the emulator can limit the number it wants to use, with the exception that if you request the synth with, say, 64 voices then the emulator will generate that many for you.
There is another option that might help: '-emulate obx' should only assign 10 voices to the synth (damn, or was that 5?). This option looks for diverse settings in the emulator itself rather than in the synth:
startBristol -emulate obx -debug 1
Feb 25 19:36:09 bristol [1.206247] created 32 voices: allocated 5 to synth
startBristol -obx -debug 1
Feb 25 19:37:57 bristol [1.066493] created 32 voices: allocated 32 to synth
The -emulate option covers other stuff such as temperature sensitive emulation, overall gain, glide rates, velocity curve. There are bristol defaults for all of these, then the emulator can have its own configured defaults (that you request with the -emulate option) then you can override them with command line options.
Kind regards, Nick.
I, personally would be inclined to have an override-able default number of voices for each synth. So that any users using the monosynths wouldn't be wondering why the minimoog emulation is polyphonic!
Also, the obx, from what it says on the vintage synth explorer website, had 4, 6 or 8 voice polyphony.
After giving this a bit more thought, I think it would be a good idea to limit each synth that has unison to its real-life max voice count.
A 32 voice-two-oscillators-per-voices turns into about a 64 oscillator monster all sounding at the exact same time, which would probably sound gigantic, but my 'measly' 2.20GHZ processor just isn't up to the task and I'd say that most other PCs aren't either!
I don't know which you'd like to do more, assign all 32 voices to all synths, except ones that need it for them to function correctly (Obxa, Jupiter, Bitone, Sidney) or change it and assign specific voice limitations to each synth per the original as default.
I might investigate the latter option myself. Out of interest, are the voices for each synth assigned inside the bristol/emulation.c folder? or in one of the header files?
Like mini.c or mini.h for the minimoog?
No matter, I'll just take a look at the source code later today.
The next release of the code will include optimised filters, the complex maths has moved into the feedback loop only and cuts CPU load by about 90%. A single voice would previously run to 25% on an 800MHz CPU, now running at about 5%. This will now become the default filter. On a reasonable CPU (2GHz+) the load per voice will be just a couple of percent and it should run 32 voice unison.
I am verging on advising '-emulate pro52' here which does all this and lets you override the settings where you prefer. The emulate settings are a part of each GUI code in brighton/brightonMini.c and the rest. The reason it is in the GUI is that the GUI tells the engine what to do, including size of voice table and voices per emulator. It should be documented (a bit) in brightonMini.h which is used by all the emulator GUI. It was the first header file and contains structures used more generally.
Hm. Those filters may have been optimised, But I still get the exact same thing as before..
Probably a problem with my jack settings?
To make sure this is not some other issue, have you also tried it now with -lwf and also with '-emulate pro52'?
I had posted that when testing the obx emulator (obviously this enhancement is to the pro52 unison). The pro52 emulation works fine with 32 voice unison (with a rather lovely hefty 65% CPU hit!).
Ah, the OBX. That is kind of bad news, sloppy on my part. These emulators do use different filter code however I had intended to have both of them implement this same optimisation. They don't, the changes were not implement consistently.
A change will be posted here, it affects a file called filter2.c that goes in the bristol directory. It affects three emulators, the OB-X/a, BME700 and the ARP2600.
Nice CPU figures! Not too bad though really, it indicates 2% per voice including osc/env/filter, etc, in line with what I have seen here for a 2.2GHz system and a considerably improvement on nearly 10% per voice seen previously.
Kind regards, and many thanks for reporting this, I would not have found it.
This is a fix for 0.50 filter use, resolved in 0.50.4 and above
This is going to be closed. The filter.c is now in the mainstream code 0.50.4 due to be distributed shortly.
As a side note of this thread: I am probably going to recode the flag options such that 'emulate' is the default. Something like this: when you give the option for the emulator you want to run then bristol will pull all its emulator preferences for note count, note precedence, sensitivity, etc, as per your suggestion, and allow them all to be overridden. It seems to make a lot of sense.
Kind regards, nick
Code has been distributed. Closed.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.