On 9/20/06, Jouni Rinne <jouni.rinne(a)luukku.com> wrote: Bristol has always been that quiet. For years. I don't know why the developer doesn't fix it. Now htat it has jack support, that's easy enough to remedy. Can anyone familiar with the synths it emulates comment on their quality (besides lack of volume)? Now who's got a LASH patch for this?

On 9/20/06, Nick Copeland <nickycopeland(a)hotmail.com> wrote: I really love the sounds of this synth, but one thing that is a little aggravating (and I've noticed this on other synth GUIs as well) is that it is so hard to adjust the knobs in a "fine-tuning" way. It would be really slick if you could, for example, right click on a knob and have it change into fine-tuning mode. Just a thought. :-) -TimH

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/

I just wanted to followup on a previous message, since I had reported inability to get Bristol to respond to MIDI events, or to cooperate with JACK on my system ... On Wed, 20 Sep 2006, I wrote: Figured this out first: I had JACK set to 44.1KHz, for a project I'm working on. Changed it to 48KHz, and it's fine. I'll have to see if there's some way to programmatically _check_ the sample rate that JACK is set to, and use that in a script to start Bristol with (using appropriate sample-rate options), I think, so that I'll be able to give myself a simple menu of Bristol emulations to choose from. :-) If I can make it suitably elegant, I'll submit that as a patch to the startBristol script, but I'll know more whether what I do is worth considering for than once I've done it. Worst case, at least on my system where I use Qjackctl, it looks like I can just look for jackd in a process listing and use its "-r" argument to determine the sample rate. Figured this out as well: I needed to manually add a MIDI input connector to JACK for Bristol, and "connect" the hardware MIDI device to it, then _activate_ that new setup. Now I'm able to use Bristol with my MIDI keyboards (haven't tried yet with the guitar-to-MIDI converter, but I expect that will work as well, though the converter generates a lot of pitch-bend information. Right. No response to pitch-bend or mod-wheels, it seems. Those are the two I consider most important, though I realize that once you solve the general case, these will easily fall into place. My MIDI keyboards are (classic?) synths in their own rights (an ESQ1 and a DW8000), so I'm not looking to assign banks of 8 knobs and sliders to various parameters, but the ability to use the pitch-bend and mod controls on Bristol from the keyboards would be fantastic. Also, program-change commands, if that isn't already inplemented (I haven't actually tried, I admit). I'm very happy to report this now works for me! :-) :-) :-) Thank you VERY much, for all the work you do on this, Nick! -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)alcor.concordia.ca Major in Electroacoustic Studies Concordia University Faculty of Fine Arts / Music Department Montreal, Quebec, Canada ----------------------------------------------------------------------

On Sun, 1 Oct 2006, Nick Copeland wrote: Will try that (hopefully this evening). It sounds like at least the most important (to me) items I've brought up are addressed in that version. Thank you. I wonder if this is what caused a symptom I've occasionally noticed, particularly with some of the emulations where it seemed at times that the envelopes weren't always retriggering. I wasn't yet sure whether this was due to anything of my own fault (anything from the retriggering getting lost within my setup to perhaps simply poor playing technique). If this symptom is no longer noticeable with -66, then that must be it. Otherwise, I'll try and narrow it down before "officially" reporting it. I can be patient. :-) Thanks again! -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)alcor.concordia.ca Major in Electroacoustic Studies Concordia University Faculty of Fine Arts / Music Department Montreal, Quebec, Canada ----------------------------------------------------------------------

Build 89 has been uploaded to sourceforge. It is likely to be unstable since quite large changes were made to the MIDI interface to support controller tracking in the GUI. The 2600 should now be finalised including the output bussing fixes and voltage manipulators. The sustain pedal should now work, lightly tested. MIDI controllers can be remapped internally, only interface is the text configuration file in $BRISTOL/memory/profiles/<synth>, you can edit this at your own risk. Controller changes allow for MIDI surfaces to control the GUI, and hence the engine. Rather spuriously, to be able to modify and play the synth then both the GUI and engine need to be patched into the MIDI devices with whatever connection application you prefer - controller changes are tracked in the GUI and this causes the parameter changes to be sent to the engine. Having this support immensely enhances tweaking the synths. You can map controllers by clicking the middle mouse button in a device and then moving the desired controller. You can select multiple devices to enable ganging of controls and the controller profile should be maintained. The mappings for each algorithm are saved when a patch is saved. They are only loaded on boot, but mappings should not be volatile. Reselecting a device with the same middle mouse button will remove the registration. Pitch and Pan controllers should now be notched in the GUI, and a fine adjust is available with <Control><Button_1_Motion>. The rotary shading was altered and a few other fixes were integrated. The transparent patch layer was optimised bya factor of 4 to 5 fold so loading the 2600 memories should be a lot faster. Feedback on the controller mappings would be greatly appreciated, the interface is new and will probably give some problems. When the interface works then program change support will be integrated along with more GM2 functionality. Regards, Nick. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Le 23 Sep à 08:30, tim hall ecrivait: You should try the last version, it's really awesome. Jack support works perfectly, I'm now working on the official doc of the ARP 2600 to re-learn and re-think the basis of synthesis and learn how such a wonder could work. ( http://guitarfool.com/ARP2600.html ). Nick, great thanks for your work :). Cheers, Y.

There is no 'install' capability. I could put one in, its just that I don't like attempting to tweak other peoples computers so had the startBristol script look for its libraries, binaries and bitmaps in its own subdirectories. The main issue is with the bitmaps and memories, they don't really have a 'correct' location. Yes, the patch transparencies are a bit of a performance hog, that is really noticable with the memories as to maintain this layer each patch has to be independently removed. This is not really necessary for memories, I still intend to implement a 'clear all' option that is actually implemented in the engine (it was needed to ensure that bristol and brighton were in agreement on the patches. Optimising all the color management and bitmap rendering code is on my wishlist which will improve that also. At the moment it has absolutely no optimisation and yes, that is now noticable. Since the transparency layer is also going to be used for other features I will work on some changes. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

On Mon, 2006-09-25 at 15:39 +0200, Malte Steiner wrote: 3D hardware acceleration requires a proprietary driver on most machines. Please don't make it a requirement. Lee

I have considered OpenGL, but bristol currently only has dependencies on an audio library in the engine and Xlib for the GUI. I have previously written and maintained applications that had other dependencies and they are painful to manage - not just for development, but also for installation. There are so many audio tools out there, and many have their own different set of requirements, its actually quite a ludicrous situation. That is not too slight any of the applications, they are written for free, writing them has to be enjoyable for that reason, so it is reasonable that they use whatever toolkit feels right. For bristol, this toolkit was brighton, it was a lot of fun to build. I am also not convinced that 3D is where I want to go - I like the idea, but it keeps reminding me of starski and hutch style 'go faster stripes'. What I want to say is that the interface needs to be interesting and 3D would be, but this is still an audio application and 3D does not improve usability - probably one of the biggest requirements of bristol at the moment. Regards, Nick. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

On Monday 25 September 2006 15:04, Lee Revell was like: Two's up on that. My video card is one of the few that doesn't require proprietary drivers, however its DRI has been broken in Debian testing for the last few months and the fix has been a long time coming. It would have been very annoying to not to have been able to join in the fun. Fortunately, I am getting an idea of what Bristol can do, albeit with a few problems, which I'll go into when I've had time to investigate properly. Now I'm really looking forward to the possible development of a virtual Synthi size A. :) -- cheers, tim hall http://glastonburymusic.org.uk/tim We are the people We've been waiting for.