[linux-audio-user] Re:Re: ANN: bristol 0.9.5-60

[Nick Copeland]

>I'm still not sure why I'm unable to use "-audiodev plughw:2,0"

At the moment all of my development is done on a laptop, my tower system is 
in storage in the UK so I don't have access to multiple soundcards to really 
test this one.

>but every time I tried to play a note [with jack] Bristol silently exited.

The engine has probably exit due to not being able to open the audio 
interface, or has core dumped. If you have coredumpsize enabled we would 
debug that case. The only reasons I know of for failing to open jack is 
permissions if you do not have the PAM modules enabled then bristol may not 
have the desired rights to connect?

>I can setup command aliases to start different synths at various gain 
>levels

Ah, at the moment you can't, the final stage output gain is in the audio 
engine, not in the emulation, so it applies to all synths. I can change this 
reasonably quickly though, next upload should be able to do this by synth 
since the feature looks like being useful.

>Well, I would like to be able to control it via MIDI from an external 
>keyboard

This does work, in as much as it was architected to support this and other 
people report that it works. I will be testing with a USB keyboard this 
weekend so may get you an update.

>manipulate "standard" controllers (pitch and mod wheels, damper pedal, 
>[etc])

Here is the lowdown on MIDI in bristol. The GUI and the engine are separate 
processes. They speak SYSEX messages to adjust the parameters, and the 
keyboard sends NOTE events - all across a TCP socket primarily from GUI to 
engine (there are some acknowledgements). Separately the engine listens, per 
default, to the ALSA SEQ or raw MIDI interface for MIDI events. It only 
supports the following: NOTE ON/OFF, CONTINUOUS 0 and 1 for pitch and mod 
wheels, and the memory moog should respond to controllers 7 and 11 for two 
foot pedals - expression and volume.

I was not sure whether to implement the sustain pedal. Most master keyboards 
will use this to control sending note off events for sustain, so bristol 
then does not have too.

Now when it comes to controlling parameters, this is a GUI function. The GUI 
will have to register to receive MIDI events as well as the engine, change 
its potentiometer settings and then tell the engine to adjust its 
operational parameters. Also for program change events it is the GUI that 
has memories, not the engine. In my opinion this is the correct approach, 
but it introduces a couple of issues regarding controller manipulation. 
Either way controls will be implemented and I will maintain an option for 
tracking the keyboard in the GUI for the reasons you state.

The engine will eventually conform a bit closer to the GM2 specification, 
which means it will allow you to control filter and envelopes, etc, with 
some default controller numbers as per that spec. No dates for this.

The keyboard graphic has been reported as being 'klunky' to use, and that 
its model of click on/click off is arguably wrong. It was never intended to 
actually play the synth using this keyboard, it was put in for a couple of 
reasons - firstly it looked good, the GUI should be able to represent the 
original instrument. Secondly it allows me to at least test and control it 
without having to have my master keyboard attached (and seeing as that is 
also in storage, just as well). On related note, the ARP 2600 has a button 
next to the envelope controls that allow you to generate sounds without a 
keyboard - this is the same as the original unit and again allows testing a 
synth that does not in this case even have the keyboard graphic.

>Maybe a blinking "LED" to acknowledge receipt of MIDI data, though?

For future study. There are issues here regarding the fact that the engine 
and GUI are separate processes - the LED should reflect MIDI traffic in the 
engine, but that would require the engine inform the GUI that events have 
occured, itself an overhead and outside of the current communication model.

>an MS20

The main issue I see here is that whilst bristol does take a copy of the 
input data and present it to all the synths (the Mini/Explorer have external 
inputs, the ARP also but not widely tested) to manipulate the sounds, the 
MS-20 had this groovy Hz->Volts converter, allowing it to be used as a 
vocorder. This is notoriously difficult to emulate digitally, but it is down 
on my list. It is likely to first appears in something called a 2610 or so, 
the ARP 2600 with additional voltage manipulators (inverters, lin/log, spare 
mixers) as per the original instrument, but also with this frequency to 
control signal extractor.

>the mixer is intended to be usable to mix and process multiple instances of 
>Bristol?

The honest truth is that I have really specified what the mixer will be for. 
It is intended to be a realtime mix for both audio and emulated streams, and 
the intention is to use multichannel hardware and also to register multiple 
IO with Jack to allow it to remix audio from different sources. The thing 
is, Ardour already does this and a lot more exceptionally well, so with Jack 
integrated into bristol kind of removes the requirement for a bristol mixer. 
Having said that I like mixers and I like the bristol mixer interface, so it 
will happen at some point. There are a lot of differences in the design of 
these two mixing apps - I kind of like the sometimes rather kluterred 
bristol mixer interface rather than a load of drop down menus and screens. 
Personal choice.

>the Synthi 100 was a massive unit

I was more thinking of the A series, the 100 graphics would not fit on any 
reasonable monitor! That is not to say I would not consider something like 
the Synthi 100, just not right yet. Put it this way, I wanted to have an ARP 
2600 but knew that would be a lot of work, a big learning curve, so before 
starting on the 2600 I implemented the Axxe and Odyssey. The Axxe gave me 
the right operator set, the Odyssey added in the routing capabilities via 
switches, and finally the 2600 tied them all together with the patching 
interface. This was also done for the OBXa (did an OBX first) and for the 
Prophets (did a 5 before a 10). The same would happen with the EMS synths as 
well.

>Moog Taurus?

Am not convinved - you would need to do a sales pitch on me.  The other 
synths can do the sounds, and I am not sure I want to work on the graphics 
for a pedalboard.

Kind regards,

Nick.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/