~ubuntu-branches/debian/squeeze/bristol/squeeze

« back to all changes in this revision

Viewing changes to ChangeLog

  • Committer: Bazaar Package Importer
  • Author(s): Alessio Treglia
  • Date: 2009-11-10 12:21:04 UTC
  • mfrom: (1.1.2 upstream)
  • Revision ID: james.westby@ubuntu.com-20091110122104-432yau0haobyl122
Tags: 0.40.6-1
* Adopting this (Closes: #546954).
* Create new bristol-data runtime package, it will contain application's
  architecture-indipendent data files.
* Drop all patches, now useless.
* Switch to debhelper 7.
* debian/copyright: Update according to DEP-5 spec.
* debian/bristol.1: Fix little spelling mistake.
* Replace patch system, from dpatch to quilt.
* Add 01-spelling_errors.patch patch to fix spelling-error-in-binary.
* debian/rules: dh_makeshlibs doesn't touch shlibs/symbols file, libraries
  under /usr/lib/bristol/ are private.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
1

2
 
Fix up floatmap to be frequency tables again, use an fTab with parsing rather
3
 
than a float array.
4
 
Rework the microtonal tables for fTab support also.
5
 
Rework the glide for both table types.
6
 
Rework monophonic note logic
7
 
 
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.
17
 
 
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
22
 
artifacts.
23
 
 
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.
32
 
 
33
 
Consider putting shade layer into App and manage resizing (no, -scale...)
34
 
 
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
40
 
not the cause.
41
 
 
42
 
Mixer, Jack MultiIO, 2600 Cables, MS-20, DX enhancements.
43
 
 
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.
46
 
 
47
 
Engine lockout (still functions but system cannot move much...).
48
 
 
49
 
Push BLO into Juno DCO - no, perhaps NRO preferably.
50
 
 
51
 
Rework detuning for less span and more resolution.
52
 
 
53
 
Fix saving sequences.
54
 
 
55
 
CS-80:
56
 
Second channel
57
 
Filter env
58
 
Volume management
59
 
RM env and osc
60
 
Touch response to osc
61
 
FX
62
 
Glide
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.
65
 
 
66
 
MG-1
67
 
Waveforms very similar
68
 
Key tracking too aggressive (also on MemoryMoog).
69
 
 
70
 
BEFORE RELEASE 0.30:
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
76
 
look at the rest.
77
 
 
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 
82
 
        questions.
83
 
 
84
 
    -bitone            - crumar bit 01 REWORK
85
 
    -bit99             - crumar bit 99 REWORK
86
 
    -bit100            - crumar bit + mods REWORK
87
 
    -jupiter           - roland jupiter-8 REWORK
88
 
 
89
 
        /*
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
93
 
         * from normalised
94
 
         */
95
 
    -explorer          - moog voyager
96
 
    -voyager           - moog voyager electric blue
97
 
    -cs80              - yamaha cs-80 (unfinished) TEST
98
 
 
99
 
Memory Moog Envelope tracking attack is broken. Bit-1?
100
 
 
101
 
ARP 2600 oscillators are rather LF when in LFO.
102
 
 
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.
106
 
 
107
 
Elke Synthex
108
 
 
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
113
 
 
114
 
Leslie fixes.
115
 
 
116
 
 
117
 
 
118
 
 
119
 
 
120
 
 
121
 
 
122
 
Somewhere in these releases there is also the request for DSSI and LV2
123
 
support that needs to at least be considered.
124
 
 
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
 
3
 
 
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.
 
8
 
 
9
Included some memory packs for the trilogy and polysix emulators.
 
10
 
 
11
    0.40.5 23 Jul 2009 Distributed processing maintenance release
 
12
 
 
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.
 
29
 
 
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.
 
37
 
 
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.
 
43
 
 
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.
 
49
 
 
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.
 
53
 
 
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.
 
56
 
 
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.
 
65
 
 
66
    0.40.4 06 Jun 2009 Audio Driver Mainenance Release
 
67
 
 
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.
 
71
 
 
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.
 
76
 
 
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
 
79
ALSA driver versions.
 
80
 
 
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.]
 
89
 
 
90
    0.40.3 25 May 2009 Maintenance release, B3 stuck notes.
 
91
 
 
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.
 
106
 
 
107
Releases 0.40.1 and 0.40.2 will be removed from the download site.
 
108
 
 
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.
 
119
 
 
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.
 
127
 
 
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.
 
135
 
 
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.
 
138
 
 
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).
 
142
 
 
143
The OB-Xa 4-pole filter was incorrectly mixing its feedback loop, silencing
 
144
the output signal. The 2-pole worked correctly.
 
145
 
 
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.
 
150
 
 
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.
 
160
 
 
161
    0.40.2 05 May 2009 Maintenance release, usability improvements.
 
162
 
 
163
This is primarily maintenance for the last couple of releases including fixes
 
164
to the SID emulator and some ARP improvements.
 
165
 
 
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.
 
174
 
 
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.
 
191
 
 
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
 
199
be scripted.
 
200
 
 
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.
 
207
 
 
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.
 
212
 
 
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.
129
217
 
130
218
    0.40.1 25 Apr 2009 Commodore C64 SID emulator
131
219