Been playing with the 40.1 release for a week or so now (been away from it for a bit) and lots of improvements - but I still couldn't get two synths to load at the same time. Just complied the newest version and the automatic port assignment and using audiodev to name them works excellent.
Only had time to fire up a pair of poly6's and play with them layered with a slight detuning and a bit of glide on one patch - really fattens things up nicely.
More playing tomorrow - but just wanted to say thanks!! Every new version makes this a more solid package... Its at the point now where I think I can really start playing with the fun stuff (programming) rather than just getting them operational.
One minor note that I have - I am playing with a Yamaha digital piano (no mod/pitch wheels) through a UX16 midi interface and when I start up a new synth, the mod wheel defaults to some value other than zero at startup. Not a major issue to drag it down with the mouse, but it would seem preferable to default it to zero. I'm guessing if you have a board with wheels, that an initial or periodic message is sent with the controller value (zero if spring loaded) but on a wheel less controller, it must be getting set to a random startup value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's the way it seems it should work from the info I found, but the second instance would always crash. I tried various ports form 5029 up and no go. With the new version, it just works...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The mod wheel not defaulting to zero is largely intentional, the GUI generally sends itself a modwheel setting of 0.1 so that at least some mod is active. The reason is something like this: the mods generally widen the sound, deepen it. If a user just starts the synth and hits a few keys then unless I have a default non-zero value the quality is weak, perhaps even enough for a user to disparage the application.
MIDI is stateless so there are no on-going messages for the wheel position. That means the engine never knows the current MIDI mod wheel position until the wheel is actually moved.
I could put it into an environment variable as well, if the variable exists then use its value, otherwise default to 0.1? BRISTOL_MODWHEEL?
Am very pleased to hear the multiple engines are working well now. It has taken a lot of steps to get it there, many issues due to bristol, some due to jack. Just for the record:
Should give you 2 GUI, one engine and roughly do the same thing if the ports were connected correctly except the first has two engines and the second has one multitimbral engine - both emulators will respond on midi channel #1. Both are correct and expected to work but have different capabilities.
Recent fixes went in for MIDI channel assignment failure, jack autoconnect failure, TCP port conflicts, jack port naming errors, jack midi channel/audio channel confusion, all of which made this easier to do. I will make a note to test method 2 since perhaps the polysix crashes if two are started on the same engine at the same time - it should work so maybe it is a bug.
Regards, Nick.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the clarification - as I mentioned, its not a problem to bring the mod wheel down after starting, it just seemed counterintuitive to have it default to a non-zero value.
Another item I noted is that when I look at things in Patchage, the engines are noted with their audio ins and outs, but no midi connections are apparent - whereas most other synth engines I start up (but rarely use for other reasons) have midi connections shown in Patchage. I use the jack connections window to connect my midi, so its not an issue, but often I will use patchage just to get a quick look at how things are routed when I have a bunch of stuff happening in and out of ardour. I'm guessing it may have something to do with ALSA vs JACK for midi - but its not a big deal on my end...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You can test bristol with Jack MIDI and see what the difference is but I am pretty sure Patchage supports ALSA interfaces and bristol is always visible in aconnect. The Jack MIDI interface has not been widely tested (by me) and probably not by the wider user group since I have not had any bug reports against it.
With respect to the modwheel, there are perhaps just two obvious values, these are zero and 1/2. The latter is more applicable to pitchbend and for the mod wheel that is often far too much although that does depend on the patch so I am happy to make it zero, even though I do like having a bit of effects just to that when auditioning sounds you get a better idea of what they can do.
Regards, Nick.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just for the record, I did test option 2 of having one engine run two polysix and there were no problems here. The failures you had may be due to other fixes that went into the 'multiengine' stuff work.
Regards, Nick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bristol 0.40.3 is due out soon, probably before the end of this week. It resolves a number of issues with note events - most notably the B3 would lose some note events and leave keys hanging after they had been released (as reported on LAU, now resolved as far as we can tell). Additionally there were changes to the jack signalling on startup and shutdown so that registration errors are reported and the 'subgraph timeout' error message on close has been fixed - that mean s bristol will not disturb other applications when it exits.
There is 'beta' code available from the URL below if you are interested in testing it before it is released. You may find some excess debuging in MIDI events that will be removed before finally being uploaded. If you do want to review it that would be great for me but no hassle if you don't. From my side I just wanted to make sure I had not broken anything in the process of resolving a few gritty problems that had been reported in note assignment and Jack interface coding.
Been playing with the 40.1 release for a week or so now (been away from it for a bit) and lots of improvements - but I still couldn't get two synths to load at the same time. Just complied the newest version and the automatic port assignment and using audiodev to name them works excellent.
Only had time to fire up a pair of poly6's and play with them layered with a slight detuning and a bit of glide on one patch - really fattens things up nicely.
More playing tomorrow - but just wanted to say thanks!! Every new version makes this a more solid package... Its at the point now where I think I can really start playing with the fun stuff (programming) rather than just getting them operational.
One minor note that I have - I am playing with a Yamaha digital piano (no mod/pitch wheels) through a UX16 midi interface and when I start up a new synth, the mod wheel defaults to some value other than zero at startup. Not a major issue to drag it down with the mouse, but it would seem preferable to default it to zero. I'm guessing if you have a board with wheels, that an initial or periodic message is sent with the controller value (zero if spring loaded) but on a wheel less controller, it must be getting set to a random startup value.
I always thought the way to get two synths at the same time (running on one engine at least) was to do:
startBristol -jack -count 1024 -b3
startBristol -jack -channel 2 -sidney -engine
for example.
I've also noticed that modwheel thing, but I've never reported it, I never really considered it a bug..
Andrew.
That's the way it seems it should work from the info I found, but the second instance would always crash. I tried various ports form 5029 up and no go. With the new version, it just works...
The mod wheel not defaulting to zero is largely intentional, the GUI generally sends itself a modwheel setting of 0.1 so that at least some mod is active. The reason is something like this: the mods generally widen the sound, deepen it. If a user just starts the synth and hits a few keys then unless I have a default non-zero value the quality is weak, perhaps even enough for a user to disparage the application.
MIDI is stateless so there are no on-going messages for the wheel position. That means the engine never knows the current MIDI mod wheel position until the wheel is actually moved.
I could put it into an environment variable as well, if the variable exists then use its value, otherwise default to 0.1? BRISTOL_MODWHEEL?
Am very pleased to hear the multiple engines are working well now. It has taken a lot of steps to get it there, many issues due to bristol, some due to jack. Just for the record:
startBristol -jack -polysix
startBristol -jack -polysix
This should now give you 2 GUI, 2 engine and 4 output ports in Jack (2 for bristol and 2 for bristol_5029). The alternative:
startBristol -jack -polysix
startBristol -engine -polysix
Should give you 2 GUI, one engine and roughly do the same thing if the ports were connected correctly except the first has two engines and the second has one multitimbral engine - both emulators will respond on midi channel #1. Both are correct and expected to work but have different capabilities.
Recent fixes went in for MIDI channel assignment failure, jack autoconnect failure, TCP port conflicts, jack port naming errors, jack midi channel/audio channel confusion, all of which made this easier to do. I will make a note to test method 2 since perhaps the polysix crashes if two are started on the same engine at the same time - it should work so maybe it is a bug.
Regards, Nick.
Thanks for the clarification - as I mentioned, its not a problem to bring the mod wheel down after starting, it just seemed counterintuitive to have it default to a non-zero value.
Another item I noted is that when I look at things in Patchage, the engines are noted with their audio ins and outs, but no midi connections are apparent - whereas most other synth engines I start up (but rarely use for other reasons) have midi connections shown in Patchage. I use the jack connections window to connect my midi, so its not an issue, but often I will use patchage just to get a quick look at how things are routed when I have a bunch of stuff happening in and out of ardour. I'm guessing it may have something to do with ALSA vs JACK for midi - but its not a big deal on my end...
You can test bristol with Jack MIDI and see what the difference is but I am pretty sure Patchage supports ALSA interfaces and bristol is always visible in aconnect. The Jack MIDI interface has not been widely tested (by me) and probably not by the wider user group since I have not had any bug reports against it.
[nicky@nickpc] ~ [3] aconnect -o
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'
client 128: 'bristol' [type=user]
0 'bristol input '
client 129: 'brighton' [type=user]
0 'brighton input '
I would have thought these should have shown up.
With respect to the modwheel, there are perhaps just two obvious values, these are zero and 1/2. The latter is more applicable to pitchbend and for the mod wheel that is often far too much although that does depend on the patch so I am happy to make it zero, even though I do like having a bit of effects just to that when auditioning sounds you get a better idea of what they can do.
Regards, Nick.
Just for the record, I did test option 2 of having one engine run two polysix and there were no problems here. The failures you had may be due to other fixes that went into the 'multiengine' stuff work.
Regards, Nick
Hi Clinton,
Bristol 0.40.3 is due out soon, probably before the end of this week. It resolves a number of issues with note events - most notably the B3 would lose some note events and leave keys hanging after they had been released (as reported on LAU, now resolved as far as we can tell). Additionally there were changes to the jack signalling on startup and shutdown so that registration errors are reported and the 'subgraph timeout' error message on close has been fixed - that mean s bristol will not disturb other applications when it exits.
There is 'beta' code available from the URL below if you are interested in testing it before it is released. You may find some excess debuging in MIDI events that will be removed before finally being uploaded. If you do want to review it that would be great for me but no hassle if you don't. From my side I just wanted to make sure I had not broken anything in the process of resolving a few gritty problems that had been reported in note assignment and Jack interface coding.
http://bristol.sf.net/files/bristol-0.40.3h.tar.gz
Kind regards,
nick.