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

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. 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? 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. 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. 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. 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. 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 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. 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. 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/