2
Fix up floatmap to be frequency tables again, use an fTab with parsing rather
4
Rework the microtonal tables for fTab support also.
5
Rework the glide for both table types.
6
Rework monophonic note logic
8
Tendencies: non-resampling oscillators. Or at least minimally resampling. The
9
3 main waveforms are specified as a set of parameters to an algorithm. The
10
algorithm moves a point at a specified rate according to its parameters,
11
square tend quickly to a target with a target that moves (leakage) and
12
switches high to low. Tri moves slowly to target then changes direction. Ramp
13
moves fast to target then fades. The only resampling required is one small
14
correction per cycle at the point of inflection for subsampled starting
15
points. This should work for square, pulse, pwm, ramp, saw, tri and can easily
16
incorporate PWM and Sync.
18
Consider implications of removing the oversampling code from the Houvilainen
19
filter and oversampling everything N times. The filter will need about the same
20
CPU capacity at 2x oversampling, the osc/env code is efficient anyway and the
21
benefits of oversampling everything would help remove some of the oscillator
24
The bristol key gating code is a little broken due to how midi works. In the
25
old analogue keyboards gating is really fromm the amplifier envelope, it is
26
the one that defines when the signal is audible. Bristol typically takes gate
27
from note_on/off which does not account for decay. This is not noticible with
28
most emulations because the key will gate until the envelope terminates
29
however some emulations (Axxe, Odyssey, Juno, etc) that have a direct gate
30
option and then the gate should be extended to cover decay. This is perhaps an
31
issue for each emulator rather than the engine infrastructure.
33
Consider putting shade layer into App and manage resizing (no, -scale...)
35
Master controller - don't waste too much time on this.
36
Bristol Sampler for the OLPC sample suite? Or on this.
37
Reports of NoteOff events being dropped from some midi controllers. Not seen.
38
Lots of jack overruns unless CPU at full wack. Occurs with and without jackmidi
39
which is oddly reassuring, it means the midi code although not widely tested is
42
Mixer, Jack MultiIO, 2600 Cables, MS-20, DX enhancements.
44
Monophonic issues with single voice. Mono cuts keys to early/many - note off
45
code seems damaged. Fixed, but may raise enhancement for mono note logic.
47
Engine lockout (still functions but system cannot move much...).
49
Push BLO into Juno DCO - no, perhaps NRO preferably.
51
Rework detuning for less span and more resolution.
63
Nudge both ways, nudge globals. Needs a button per row of globals plus a
64
controller for depth of nudges, this should be a log pot.
67
Waveforms very similar
68
Key tracking too aggressive (also on MemoryMoog).
71
Review all the gains, yet again. Baseline the filter oscillation so that its
72
signal gives the desired output, then rework the signals into the filter so
73
that they come up to the same level. This puts the filter back onto a nicely
74
resonant level and the Sonic-6 is almost in tune.
75
Work this through first with the Pro-1, then look at the result with LWF, then
78
The following really need some more work. The filters stil overdrive
79
as with the Explorer. At the moment they are just passable however it
80
is not really possible to play the filter. We could send the current
81
code out though, rework them later and bring it forward if there are
84
-bitone - crumar bit 01 REWORK
85
-bit99 - crumar bit 99 REWORK
86
-bit100 - crumar bit + mods REWORK
87
-jupiter - roland jupiter-8 REWORK
90
* These still need work on the filter, there seem to be issue with
91
* scaling the signal versus the resonance - they both go up rather
92
* than just the input sigal. It basically works but the signal is far
95
-explorer - moog voyager
96
-voyager - moog voyager electric blue
97
-cs80 - yamaha cs-80 (unfinished) TEST
99
Memory Moog Envelope tracking attack is broken. Bit-1?
101
ARP 2600 oscillators are rather LF when in LFO.
103
Jupiter panel select needs some work. If mode is all we should auto select the
104
lower panel. Also, filter needs working out for gain levels regarding the
105
type so probably need to review all the LWF options.
109
Odyssey LFO tracking env is damaged in uni mode.
110
Pro-1 LFO tracking env incorrectly synced
111
Pro-1 memory load option not working
112
DX loops on mem change
122
Somewhere in these releases there is also the request for DSSI and LV2
123
support that needs to at least be considered.
125
0.50.Z XX Yyy 2009 Mixer.....
126
0.40.Y XX Yyy 2009 MS-20, AKS.....
127
0.40.X XX Yyy 2009 Yamaha CS-80.
128
0.40.W XX Yyy 2009 Roland SH-101
2
0.40.6 23 Jul 2009 Maintenance release
4
Resolved a name resolution issue that would cause the split/layer keyboard
5
emulators to fail. The dual manual ones should have worked. The workaround was
6
to default the hostname when null but the actual fix is to request the same
7
destination host in all cases, something that will now only go into 0.50.
9
Included some memory packs for the trilogy and polysix emulators.
11
0.40.5 23 Jul 2009 Distributed processing maintenance release
13
Added an option to startBristol, -gui, which will prevent the GUI from being
14
started and invoke the engine with all the resolved bristol variables. This
15
will allow for easier distribution of the applications with GUI and engine on
16
different hosts, this was always a part of the design but was never really made
17
that accessible. This can be used in conjunction with the -server flag which
18
will leave the engine active even when the last emulator has disconnected.
19
Running as a server lead to a few issues that were anticipated - constantly
20
reconnecting GUIs would exhaust various engine tables that were not being
21
cleaned up correctly as this had never been widely used. The file descriptor
22
table was not being cleaned up, the handle and device tables similarly. There
23
was an issue with SID selection of the EXIT requests not being correctly matched
24
causing the wrong emulators to be disconnected, and with failure to correctly
25
close input file descriptors on active sense failure requiring a small change
26
to the device reading logic. It was finally possible to run a test script to
27
reconnect several hundred times without failure, all emulators still audible
28
and so moved to released code.
30
Several issues arose whilst building the application without ALSA drivers. This
31
is supported, especially now that Jack MIDI is integrated, however since ALSA
32
turned 1.0 the coding has been a bit lax, assuming that ALSA was available and
33
integrated. The result was that building without ALSA might fail and that even
34
when compiled there were issues with device open() requests. Resolved these and
35
added the flags required to accept note events over the control link so that
36
GUI keyboard events are still tracked even if the ALSA code is not integrated.
38
Was requested to remove all OSS dependencies from the build process as well.
39
This was a little more work than ALSA since that was always intended to be a
40
build option, OSS by contrast was always anticipated to be present. Had to
41
clean up some of the socket toolkit header files and some erroneous definitions
42
in the midi library that was being flagged by some more meticulous compilers.
44
Reworked the TCP addressing code to accept -host <hostname:port> where hostname
45
can naturally be a IP address or (non)canonical hostname. The port option can
46
be used with the -engine flag to connect the GUI to a specific host where the
47
engine is running, remotely: it is an alternative to the -port flag however
48
it is still advised to actually use -port for other reasons.
50
There was some general code cleanup from the request to have bristol function
51
on a system that had neither OSS nor ALSA installed. This was never anticipated
52
and making it possible brought other issues to light.
54
The Trilogy had a very unequal mixing section, the organ gain was too quiet
55
and the synth section too loud. These were evened out.
57
The Trilogy also had some rather unusual use of volume controls. To reduce
58
CPU load the synth would not run the organ and string sections unless they had
59
a non-zero gain. This achieved its affect however the result was that if the
60
gain was zero at note_on then the voice would be muted (it actually just fell
61
through the note logic and turned itself off). The fix was to always run the
62
oscillator divider circuit envelopes under all circumstances to engage the note
63
logic. The audio generation code is still skipped as it would be silent anyway
64
when the gain is set to zero.
66
0.40.4 06 Jun 2009 Audio Driver Mainenance Release
68
Added an autodetect for Jack where a small program will connect to the daemon
69
and find out the sampling rate and period size. These are then given to bristol
70
as parameters preventing unexpected mismatches later.
72
Fixed a watermark issue with the ALSA drivers, the high available threshold was
73
too low which causes the library to report false overruns. Since these come
74
back as a failed write operation the bristol audio library was restarting the
75
audio devices. The diagnostics reported this as a broken pipe.
77
Resolved a typo in the ALSA drivers that damaged the periodsize and buffersize
78
matching. Caused cyclic ticks in the output stream depending on hardware and
81
Changed the activesense period to 3s and timeout to 15s. There are issues when
82
running with RT scheduling where the GUI may get starved when there is a lot
83
of audio activity causing the engine to give a false positive of a GUI failure.
84
Since active sense is really there to make sure everything exits gracefully
85
when there really is a failure then the timers need to be more flexible to
86
cater for situations of high CPU load. [0.40.5: as a side note, this only
87
really affected a system if it had cpu-speed ondemand, or was massively over-
88
loaded, neither of which are optimal for audio processing.]
90
0.40.3 25 May 2009 Maintenance release, B3 stuck notes.
92
The Bristol B3 was exhibiting stuck notes, fairly arbitrarily however the
93
issue was not reproducable on the development system. After a ludicrous number
94
of debug builds to get different statistics the cause turned out to be the B3
95
postOpts which manipulated the voice flags and the resolution was to extend
96
the semaphore coverage to include emulator postopts. Theoretically it would
97
be possible to have just changed the B3 code however the engine that hosts
98
the emulator should not be open to flag abuse in the voices and the voices
99
are allowed to manipulate these flags. The actual cause was a race condition
100
that only really exhibited itself on multicore/HT systems.
101
Thanks to Andrew Coughlan and Damon Chaplin for the report and debuging
102
output to isolate this issue. As the problem was not reproducible on the
103
development system (single core) then tracking down the cause required a
104
number of different debug revisions and a great deal of patience and output
105
logging from the people involved.
107
Releases 0.40.1 and 0.40.2 will be removed from the download site.
109
The bristol shutdown procedures were not really compliant with the Jack API
110
definitions, they would not deactivate/unregister the active handles before
111
exiting. This does not work very well with multiapp environments, it causes
112
a subgraph timeout in the API. Changed the shutdodwn code sequences so that
113
the last exit operation will clean up the emulators in the audio thread and
114
let the MIDI thread then unregister jack and exit so that all parties are
115
happy. Also added some diagnostic output in the event that ports cannnot be
116
registered - this happens if Jack has a lot of application ports to deal
117
with so the additional message makes sense. Also coded in jack_client_open()
118
to replace the now deprecated jack_client_new() previously being used.
120
The Sidney emulator was about 1/2 a semitone out. After a lot of delving into
121
the correctness of the code without much success (ie, it seemed correct) it
122
turned out the C64 had different versions for NTSC and PAL, with different
123
CPU clock speeds. The frequency tables were built from data taken from what had
124
to be a confused manual since they did not match up for the clock speeds. When
125
the due correction was applied (0.985 to 1.02 and finally 1.023MHz) it was
126
finally pitched correctly.
128
The trigger events for the SID MOD Env were not really correct. Any accepted
129
note_on event would cause them to trigger however in light of the way voice
130
separation happens it really required that the Env was only triggered if it
131
would have a affect on the given voice. There were a few cases, voice goes
132
via the filter and env modulates the filter or if the Env modules the voice
133
that is being activated. Added the logic. Voice-2 arpeggiating never triggers
134
the envelope, only its own envelope.
136
Increased the minimum Sidney arpeggiation step, it was a ludicrous 0.3 ms, it
137
is now a more reasonable 16ms. Maximum stays the same at roughly 250ms.
139
The Sidney emulator had an issue with some memories and its keymode settings,
140
the indexes were not converged correctly resulting in the radio buttons not
141
working normally (double selected radio buttons).
143
The OB-Xa 4-pole filter was incorrectly mixing its feedback loop, silencing
144
the output signal. The 2-pole worked correctly.
146
The MIDI library was altered such that all messages now carry a sequence
147
number, it's only u32 but its only use is debugging events and with the typical
148
event rates this will last far longer than any session. Also finally fixed the
149
event timestamps which were previously just null.
151
The midi and audio threads had different scheduling algorithms, one was FIFO
152
the other RR. Since the two threads used semaphores for a critical code
153
section for note events then there existed the possibility that the midi thread
154
could cause large delays to the audio thread by taking the semaphore and then
155
getting pre-empted. The fix was pragmatic, both thread have been made FIFO
156
with different priorities. A full fix would also have been to adjust the
157
thread priorities in the critical code however the current fix works except
158
when there are multiple RT programs running and that should only be the case
159
if they are all audio threads.
161
0.40.2 05 May 2009 Maintenance release, usability improvements.
163
This is primarily maintenance for the last couple of releases including fixes
164
to the SID emulator and some ARP improvements.
166
The SID synth has more key assignment modes, both arpeggiating, visible in the
167
GUI as Arpeg 1 and Arpeg 2. They will split the keyboard at MIDI note number 52
168
then assign two voices to one half and one voice to the other. Arpeg-1 has its
169
function on the upper half, leaving the lower half as a duophonic synth
170
allowing an arpeggiated chord as rythm for a bass sequence. Arpeg-2 will do the
171
opposite, it will arpeggiate on the lower half allowing for arpeggiated rythm
172
with a duophonic lead solo. These were seen as an improvement over the previous
173
but the results need to be reported back.
175
Bristol will now check the system for the availability of the TCP control port,
176
defaulting to 5028. The application behaviour has always been that an engine is
177
attempted every time the application starts and correctly speaking if a user
178
wants to work multitimbral then the second request should be given the -engine
179
option. Without this flag it still worked but was sloppy, the second engine
180
would fail to get its control port and so would exit, the second GUI would
181
still connect to the first engine and start a second emulator. The current
182
behaviour is that each time the application is started it will look for the port
183
availability and if it is already taken then an upwards scan is done from the
184
port number looking for a free socket. The port can be specified explicitly
185
with the -port option if fixed ports are required however this is not a real
186
requirement if the -audiodev is used with Jack, for example, to specify the
187
registration identifier for the new engine. If no engine is requested the GUI
188
will just attempt to connect to the specified port although arguably it should
189
check to see if the port is open - this is kind of done implicitly when the GUI
190
attempts to connect to the port.
192
Extended the BRISTOL_AUTOCONN by adding the following environment variables,
193
BRISTOL_AUTO_LEFT, BRISTOL_AUTO_RIGHT and BRISTOL_AUTO_IN. If these are set
194
they will be searched in the relevant ports list and then connected up. This
195
only happens in conjunction with AUTOCONN. On my systems this was tested by
196
setting them to system:playback_1, system:playback_2 and system:capture_1
197
resprectively, and by leaving them unset. Will see how much use they are,
198
since they are environement variables then to be useful they would have to
201
Submitted code to repaint transparency layer devices when windows sizes are
202
changed. This affects shadow layers and transparencies (such as the ARP 2600
203
patch cables). Prior to this the objects painted on to this layer were lost
204
which was confusing with the ARP at least. The effort to do this was considered
205
preferential to the alternative which was to fix the window size once defined,
206
not allow resizing and just have the -scale option at startup.
208
There were some compilation issues due to the SID test program not having the
209
correct dependencies. Removed sidtest from the distribution, it is no longer
210
required, it was only used to exercise the bristol softSID chip until it was
211
integrated into an emulator, now done.
213
Known issues are that the Pro-10 would fail on some systems. This is a very
214
specific issue as some systems have been reported not to suffer from the
215
issue. A workaround is in place however a longer term resolution will have to
216
be sought and a bug is open against the issue.
130
218
0.40.1 25 Apr 2009 Commodore C64 SID emulator