>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/
Received on Fri Sep 22 08:15:04 2006
This archive was generated by hypermail 2.1.8 : Fri Sep 22 2006 - 08:15:05 EEST