-
Notifications
You must be signed in to change notification settings - Fork 13
/
Copy pathNEWSLETTER
2459 lines (1958 loc) · 135 KB
/
NEWSLETTER
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
svn diff -r "{2013-01-01}:{2013-01-31}" | diffstat
git diff --shortstat @{2013-01-01} @{2013-01-31}
git diff --shortstat RELEASE_0_8
2014/12 ========================================================================
Now that two month passed since the release, I have a little update on whats
going on. First we moved all the bugs over to github too, I love the way you can
link things together over there. We also did a bug scrub and filed more ideas as
tickets.
On the code base I ported all GtkTables to GtkGrid as the former is deprecated.
A few of the dialogs got simplified in the process. We've fixed a few of the new
tickets to improved the UI. As one of the first new features, we now have Alsa
sequencer support. That means you can e.g. use vkeydb to control machine para-
meters in buzztrax.
Joe started to run builds on MacOS and filed lots of tickets for portability
issues. Two modules should be good by now - buzzmachines and bml. We proceed
with the others next.
In the core I improved error handling for song-io. All API now has GError
details of what went wrong.
87 files changed, 3440 insertions(+), 999 deletions(-)
2013/08 ========================================================================
- collecting gtk3 work-arounds
2013/07 ========================================================================
The last two month I mostly worked on porting the UI from gtk+2 and gnome-canvas
to gtk+3 and clutter. First I ported our own widgets (vumeter, waveform-viewer
and pattern-editor). This was relative straight forward. One issue were the
colors. I was using GtkStyle->bg[state] to draw the background, but the color
there is simply wrong. Will have to see if things look better if I use
GtkStyleContext.
I also wrote a prototype for a gnome-canvas replacement using clutter. This
looks nice now and I am quite excited about the potential for adding nice stuff
in the future. Clutter is a lot more powerful than gnome-canvas.
Right now I am in the middle of porting buzztrax-edit to gtk3. The application
already compiles and starts. Getting it back to compile was about two evenings.
Biggest work was to replace the v/h widgets with the orientable variants. After
that came a lot of soft-breaks, e.g. "expose-event" signal -> "draw" signal.
Some of the things are documented, but e.g. what to do as an application if you
where using the "size-request" to provide a sane natural size to scrolled
windows is left as an exercise to the reader :/ Next came attacking all the
layout changes. I've figured solutions/hacks for many of them, but I guess this
will keep me busy for a while.
On the machine view, I'll also need to do a lot more work. The basics work, but
there is quite a few things commented out still. Many thanks to the folks in the
clutter irc channel for their help so far.
700 files changed, 21979 insertions(+), 17892 deletions(-)
2013/05 ========================================================================
We applied as an organisation to take part in the Google Summer of Code program,
but got rejected mainly due to the project name. As this was not the first time
people where uncomfortable with the name, we renamed the project - buzztard is
now called buzztrax. The homepage with the wiki and wordpress already got moved.
The renamed codebase is online at github [1]. The mailing lists have been
migrated to buzztrax.org. A few things still need to be fixed (e.g. file
releases).
Besides the renaming there are also some improvements on the code side. I am
probably the last one to discover the g_signal_handlers_disconnect_by_* macros.
Using these made the code a bit leaner. I also worked on the level-meter
features. I did some cleanups on the widget. The syncing code is more efficient
as we listen to sync-messages on the gstreamer side to avoid another thread
round trip. Song rendering can disabled the level-meters for less noise on the
screen and some performance savings.
The song-rendering now uses the TOC support in gstreamer-1.0. That means that
the labels of a song (intro, chorus, break, ...) will end up in wav and flac
files right now. When other formats support toc, this will automatically work
for those formats too. The flag in ogg muxing got fixed in upstream and now
works for us again.
[1] https://github.com/Buzztrax
56 files changed, 715 insertions(+), 631 deletions(-)
2013/04 ========================================================================
This month I mostly cleaned up small bits and pieces from the gstreamer-1.0
port. Most notably multitrack encoding works again. The handling of EOS and
starting of the next track was racy. Speaking of the recording dialog - this one
now has some basics for a silent mode implemented. For now it only disables the
scrolling in the sequence view. Next thing would be to disable the level meters.
I hacked a bit more on the child-proxy iface. This now turned into utility
functions that allows to write:
bt_child_proxy_set(obj, "prop1::prop2::prop3", val, NULL);
So what does this do?
GObject obj1, obj2;
g_object_get(obj, "prop1", &obj1, NULL);
g_object_get(obj1, "prop2", &obj2, NULL);
g_object_set(obj2, "prop3", val, NULL);
g_object_unref (obj2);
g_object_unref (obj1);
This saved quite a few lines of C in buzztrax. I wonder if this is something we
want to add to glib? If we do I would go for a single ':' as a separator and we
might also want to consider starting the property with one:
g_object_set(obj, ":prop1:prop2:prop3", val, NULL);
The leading ':' would help to quickly detect whether we need to split the
property name and recurse into child objects. The whole scheme is backwards
compatible as property names are not allowed to contain ':'.
In the end of march I attended the GStreamer hackfest in Milano. First I looked
into a few tests - both on GStreamer and buzztrax side. On the GStreamer side
adder has some test fixes. On the buzztrax side I improved my encoding tests.
Wim gave me the crucial tip that fixed the dynamic adding/removing of analyzers
while playing. Maybe I can try that for machines again. I showed the parser for
controller-setups to some people and did smaller changes on it. I also discussed
what we could do with gst-tracelib for gst-1.0 and started a new design-draft
for it.
41 files changed, 871 insertions(+), 816 deletions(-)
2013/03 ========================================================================
As I already mentioned in last months issue, I ported buzztrax and gst-buzztrax
to use gstreamer-1.0. It will require 1.1.X for some fixes in gstreamer itself.
So how id it went. The basic porting to make it compile against 1.0 took about
20 hours spread over a couple of days. It is quite straight forward. I updated
the porting guide [1] where things were not mentioned.
The more tricky part where the soft api changes. At this port I was running the
apps with G_DEBUG=fatal_warnings. The property name changes here and there we
easy to fix. Also request pad name changes (%d -> _%u) took not too long to
handle. Other things like caps negotiation kept me busy for a few evenings. For
once I was e.g. writing GST_AUDIO_NE ("S16") instead of GST_AUDIO_NE (S16) which
leads to caps negotiation failing. Another recommendation is to avoid setting
channel-mask=3 for stereo caps. It is purely optional, most elements drop it
anyway and by leaving it out, you can merge the mono and stereo caps.
I ported freeverb in plugins-bad and made fixed to audiopanorama and adder.
Adder and collectpads have a few more new tests upstream. Another things that
took a while was getting seek-in-ready to work again. Buzztrax needs to
configure the playback segment from the application, as the sources happy beep
for all eternity. In 0.10 I could send a seek to my bin in ready, in 1.0 it gets
dropped (pads are flushing). Now I recursively iterate over sources and seek on
all of them. This is only needed to get to playing. To get these things fixed I
ported a few of my stand alone examples, but the majority of this is still left
unported.
Now the basics seem to work. I am confident that I can fix the remaining issues
in march and look forward to attend the hackfest in Milano over easter [2].
The porting for buzztrax:
69 files changed, 1909 insertions(+), 1473 deletions(-)
The porting for gst-buzztrax:
34 files changed, 1254 insertions(+), 1414 deletions(-)
The other thing I was doing this month was to experiment with embeddable
scripting engines. I wrote a toy gtk app that opens a window, sets up the
scripting engine, registers a function to get the window handle and start a
script that calls the function to get the window and adds a vbox with two
labels. I did that for lua, seed and gjs. For lua it took 30 min, for seek it
took 30min, for gjs it took 2 hours and is still not working fully (the custom
function returning a gobject).
[1] http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-1.0.txt
[2] http://gstreamer.freedesktop.org/wiki/GStreamerHackfest2013
69 files changed, 1907 insertions(+), 1507 deletions(-)
2013/02 ========================================================================
We started the year with a release in the beginning of January. So far only a few
issues were reported. Patches for these are on the 0.7.1 branch. One last minute
change in 0.7 was the departure from trying to link/unlink elements in gstreamer
while playing. I sadly have to conclude that in 0.10 this only works for some cases.
It was working sort of okayish for buzztrax, but the were still deadlocks or internal
dataflow errors from time to time. One such scenario is that when you happen to
reconnect elements while the song loops. These things are not easy to sync from the
application level. Lets hope this is easier in 1.0. The sticky events should help
with setting up the context from new elements.
On the mainline I bumped the required library version and removed the ifdefs for the
backwards compatibility. As a first bigger change, I ported the settings from gconf
to dconf. We had a settings abstraction to other gconf or play keyfiles, which we
now removed. Altogether I kept to use an intermediate object that exposes settings
as a gobject with properties for the keys. This allows to use notify to bind to
property changes instead of using a custom api.
Then I started with porting gst-buzztrax & buzztrax to gstreamer-1.0. I made good
progress. I will report the details in the next update.
77 files changed, 5892 insertions(+), 8131 deletions(-)
2013/01 ========================================================================
Happy new 2013!
Besides a lot of testing and little bug fixes here and there I finished of a few
half ready features. One is range-randomize (press Ctrl+Shift+R). In contrast to
randomize which takes the parameters min-max value as bounds, this one picks the
bounds from the first and last value in the selected range. The other one is that
now one can rename machines also from the sequence headers. I was afraid that
swapping the GtkLabel with a GtkEntry would use too much space and look ugly, but
luckily one can turn off the frame. I still get a different background color though.
During testing I noticed some inconsistencies when renaming machines and found a
rather bad data corruption. Certain interaction would create songs that won't read
back fully. One can manually fix them up (it is xml after all). I fixed the bug and
could even make the format a bit simpler. I had to touch quite a few places:
30 files changed, 246 insertions(+), 404 deletions(-)
Old songs can still be read, but songs written with the new version, also need the
new version for reading. One lesson learned, the 'id' attribute in xml is special.
Another results from testing is that the shell based test scripts can now be run
standalone to check a bunch of songs (do syntax check, print stats, convert or
encode songs).
Finally I entered string freeze for 0.7. I already received the first updates for
the translations, thanks a lot! I am looking forward to release it soon.
438 files changed, 3138 insertions(+), 2800 deletions(-)
2012/12 ========================================================================
At the beginning of the month I made a few changes to the pattern editor. It now
has a binding to the ',' key, which insert the current parameter value into the
pattern. This is a neat shortcut for using the ui to tune a parameter and then
copy the base value to the pattern. Another change in the pattern editor is that
it now shows tinted bars under the numeric values. If one ramps a parameter from
max to min, it would now show that also graphically. At some point I have to add
mouse editing.
I did a round of code cleanups. The ugly workaround for the type punning
warnings is gone, as they don't occur anymore.
I also added a new element to gst-buzztrax called 'wavetabsyn'. It uses the
wavetable oscillator component to loop a tiny grain and one can use the offset
parameter to set the position in the sample where the grain is taken from. The
osc component can now do trivial resampling, so that one can play melodies. The
new element also uses the asdr-envelope component.
The rest of the month was preparations for the next release: autofoo
modernisation, test cleanups, api-doc updates and so on. The tests now write
individual logs for each test. That makes looking at the logs of a failing test
much easier. I also silenced the remaining tests that where beeping during
'make check'. Finally I spend more time actually using buzztrax [1]. Found and
fixed a few more bugs and usability quirks.
[1] https://soundcloud.com/ensonic-1/devin
2012/11 ========================================================================
Finally pushed the pattern control-source: 26 files changed, 1204 insertions,
1333 deletions. It looks like only a little gain in code size, but that is not
true; we added more tests and splitting up a large class always comes with some
boilerplate for the new class. There are still some opportunities for
optimizations, which I'll probably try some soon.
In the UI I improved the interaction controller workflow. For controllers that
implement control discovery the dialog from the context menu will also bind the
new controller. The settings are now finally useful, as there one can do
mass-learning (tweak all knows and then go through the list and name them).
Writing synth plugins for buzztrax would be quite a bit of copy and paste. I
chopped simsyn into pieces as reusable objects in libgst-buzztrax. We have a few
oscillators, envelope objects and the svf-filter. The gst elements would proxy
some properties of the synth component. Unfortunately that means copy'n'paste of
the property setup. I've tried this code, but it shows no effect :/
GObjectClass * filter_klass = g_type_class_ref (GSTBT_TYPE_FILTER_SVF);
g_object_class_install_property (gobject_class, PROP_RESONANCE,
g_param_spec_override ("resonance",
g_object_class_find_property (filter_klass, "resonance")));
g_type_class_unref (filter_klass);
A full standalone example can be found at [1].
We also have a new element called wavereplay. This is mainly for testing the
wavetable oscillator, but also has a nice property compared to tracker elements.
It only has parameters to select the wave to play and it will play it from start
to finish in syn with the song. That is if you seek to 2:00, the wave will play
content from 2:00. This is unlike tracker elements that would only play what
gets triggered from the new time position. One practical use is doing a mixdown
of the music rendering with the vocal recordings. In such a song you load two
wave (song, vocals), use two wavereplay elements, add effect elements to the one
for the vocals and re-render the song to create the mixdown.
I thought I knew pretty much all about gobject. This month I discovered
something old I did not know about. It is supported to calls
g_object_class_install_property() for a property inherited from the baseclass to
e.g. narrow down the value range. This is very useful for the "children"
property of polyphonic elements (where children is the number of voices). The
interface does only limit the property to the full int range. With this feature
elements like e.g. sidsyn can override the range to 3...3 (sid has always 3
voices).
The last bigger change this month was a refactoring cleanup in sequence and
song-info. This was quite a big of code shuffling, but now all the timing info
is in song-info (which already has bpm an stuff). This change helped with an
optimization in the pattern control-sources.
[1] http://buzztrax.git.sourceforge.net/git/gitweb.cgi?p=buzztrax/buzztrax;a=blob;f=design/gobject/propertyproxy.c
132 files changed, 2417 insertions(+), 2138 deletions(-)
2012/10 ========================================================================
After a discussion on IRC about tunings I looked into adding some of those to
the ToneConversion class which so far only implemented the usual equal
temperament. I have to say the wikipedia articles on this matter are awesome,
detailed and plentiful. I added two 12tone tunings to the ToneConversion class
now [1] and implemented tuning in sidsyn and simsyn.
I also had a look at the TODO comments and planned items on the wiki. When I was
writing the list model classes I did not wrote ones for the wavetable and
wave-level-list. I did this now. The list models can also be tested separately
from the UI (which is harder to test). I wrote basic tests for all model classes
which bumps the test coverage in the ui by 10% (61% classes have tests now, 105
ui tests).
IRC was quite active this month. Another chat was on the wave-table page and
wave-preview. The workflow was indeed needless complicated. Now preview is a
toggle and if it is active, moving the selection in the file-browser will play
sounds. Other discussion motivated me to implement audio-device selection in the
settings. So far one could only select the protocol. Now for e.g. alsa or
pulseaudio one can also choose to which device to play the audio. While working
on the settings I started to make the interaction controller setting more
useful. So far the only use of this settings-tab was to list the detected
settings. I added a couple of messages to help the user to know what to do when
e.g. the list of devices is empty. And I started to implement batch-learning of
controls to the settings.
[1] http://en.wikipedia.org/wiki/Just_intonation#Twelve_tone_scale
84 files changed, 4199 insertions(+), 1653 deletions(-)
2012/09 ========================================================================
I worked a bit on preset handling in gstreamer. Now machines with variable
number of parameters with save their properties correctly. One example is the
parametric equalizer. I needed this for sidsyn in buzztrax too. I also updated
the preset handling for buzzmachines. They now store presets in user-data-dir.
This avoids that those get overwritten when the plugins get updated. The preset
handling logic will read user-presets first and then merge in system wide
presets. One shortcoming here is that we would need a flag on each preset
whether it comes from a preset file in user-data-dir (and thus is writable) or
comes from a system dir (and thus is read-only). This would allow the UI to
require that users pick a new uniqe name when changing a system preset.
Songs in buzztrax now also store their non-dynamic settings. This will fix
fluidsynth forgetting the selected patch file and is also needed for e.g.
setting the chip-type in sidsyn. I refactored the code a bit and now we don't
show empty properties dialogs anymore and instead gray out the menu item that
would invoke them.
The build system now can show the class-coverage of the tests. As this is just a
few shell commands it quickly shows untested classes. It relies on naming
conventions for tests. To make that work I also cleaned up the whole UI tests.
Those are now more robust and actually verify a lot more things (we went from 54
to 92 ui tests).
77 % (24/31) lib/core/
40 % ( 4/10) lib/ic
100 % ( 1/ 1) ui/cmd
51 % (27/52) ui/edit
The last thing I worked was to progress on live machine playback. And hell yes,
it works! One can bind e.g. midi keyboards to machines and play them live. This
includes a round-robin voice management for polyphonic generators. It is a lot
of fun to play with.
Tom made good progress on the pattern control source. Most of the tests now
pass. We hope to be able to merge it soon and to remove the complicated 2step
controller updating code.
151 files changed, 8453 insertions(+), 6451 deletions(-)
2012/08 ========================================================================
I started the month with some preparational work for the 2nd GSoc task - to use
GstEncodeBin for recording. The first change was to streamline the recording UI.
Instead of two dialog - one for setting and one for the progress - we now just
show one. This causes less noise on the screen and avoids us some data passing.
I also added a bunch of unit tests for sink bin to provide a means to check for
regressions when switching the implementation. This also uncovered some
unimplemented code path on the gstreamer side. Those are now fixed or handled on
our side.
In the mid of the month I could merge the encodebin transition. It is a very
decent code simplification (68 insertions(+), 113 deletions(-)). Adding new
output formats is a piece of cake now. And as a bonus, the code is now platform
independent - instead of specifying the explicit elements to use, we now specify
the container and audio track format. This way encodebin would pick suitable
elements depending on what is available.
After the audiosynth baseclass was added, I wanted to see how well it works and
started with a long time todo - a c64 sid synthesizer plugin. This wraps the
rsid library - an awesome cycle based sid emulation. The library API is quite
simple; basically:
init(); update(regs[29]); clock(*buffer, num_samples); release();
I was really happy to also see a lot of technical information about the sid chip
available on the net. When designing the gstreamer element API one needs to have
a little understanding how the chip is use to still provide a convenient access
to the parameters, but now hide important modes. That needs a bit of experiments
to decide whether individual bits need to be exposed or only certain
combinations make sense. In addition I implemented a couple of the typical
effects. The normal timing resolution of a tracker song is not too high and thus
one needs support from the element to provide things like arpeggio, portamento
and vibrato.
The sidsyn is the first more complex audio synth we have in buzztrax. It is also
the first one that uses more of the gst-buzztrax API. This was a good
opportunity to review and cleanup the APIs a bit. With those cleanups I also
killed the help interface, as new enough gstreamer has the required feature on
the element metadata side and the feature is not crucial any way.
This month I skip the git stats, as I took the indent git commit hook into use
and reformatted the buzztrax code base. Voilà: buzztrax - now with whitespace!
2012/07 ========================================================================
I did more test cleanups and finally the libs are done. I am going to increase
the coverage more, but it is quite good already. We're having more than 200 test
for libbuzztrax-core now. That helps making changes.
One aspect of writing tests is also to check the API for testability. While
working on the wire tests I noticed that we had a disabled test to check for
cycles in the machine graph. There where basics checks in the UI, which I now
moved to core as new API, expanded it to actuall do a full cycle check and
enabled the tests.
While updating the test suites I had a couple tests that I still did not like
much. They were all iterating over an array of parameters (input files,
extensions) and tested them. What is the problem? It is only a problem if things
fail. In the current setup, the test would stop on the first failing parameter.
If it would also run for the remaining parameters, I might get a better idea
what actually wrong. Besides that, I also don't see right now for which
parameter it fails (I need to log it and take a look at the log). Luckily the
Check library has loop tests. They are simple to use, instead of
tcase_add_test(), use tcase_add_loop_test() and pass the start/stop index to the
test. From within the test you can access '_i' to fetch the parameter set. If
the tests run via CK_FORK=yes (which is the default), each loop runs in a new
process.
I gave a talk at work about electronic music and used buzztrax to demo a few
things. While preparing the demos, I naturally found quite a few bugs. This
time I also wrote more tests for these things.
The other big change in the repo is the migration to non-recursive make. I
started on the buzztrax module. The first step was to still recurse into docs,
po, src and tests. That gave some nice speedup already. Then I rebased also src
and test to the project root and used includes to keep the Makefile
maintainable. This unfortunately made things little slower as I have to do:
SUBDIR = . po docs
The problem here is that the docs will link the libraries to introspect them,
but don't depend on them :/ Adding a dependency in there does not work, as the
Makefile in the docs-dir does not know the rules for how to make them.
On the slow down, the config.status run is faster (two less Makefiles to make),
but the '.' in SUBDIRS causes a recursive make invocation for the project root.
And thats where we have the big Makefile :/ The workaround I am using now is to
have own all-local, check-local, clean-local, install-data-local and
uninstall-local targets. The good thing of it is, that now the rules to build
the api docs have proper dependencies on the libraries they introspect. In
order to see how far I can speed up things, I also trimmed the includes. The
effect of this can be seen in the third group of measurements. The benchmarking
was not to elaborate, but the big picture is clear. [1]
Some general tips for how to do the change below:
* in the Makefile.am, first set all kind of vars (so that in includes you can do
VAR += ...)
* include the per subdir rules
* add common rules
* targets in e.g. "lib_LTLIBRARIES = libabc.la libdef.la" have to be in
dependency order, wtf! [2]
So far, this looks good (aka 'make distcheck' passes). Will do this for the
other modules next month.
Tom made good progress on the audiosynth base class. I just merged the branch.
Now it writing a audio synth is a lot less code.
169 files changed, 7236 insertions(+), 6459 deletions(-)
[1] http://buzztrax.org/wp-content/uploads/buildbench.png
[2] http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/Makefile.am
2012/06 ========================================================================
In May I finished the refactoring of the sequence damage-repair code for
updating the controller time-lines after pattern changes. It is a lot less code
now and it is also faster. The "less code" is important as there is quite a bit
of logic to handle combining events from patterns overlapping in time or on
several tracks.
In the same vein, I could also refactor main-page-patterns with quite a nice
code removal mount (~400 lines).
While reading "The Art of Unit Testing" [1] I decided to start cleaning up the
test suite in buzztrax. The changes so far result in tests that are more
focused, less brittle and a lot smaller. I am writing down some of the tips on
the wiki [2].
36 files changed, 2085 insertions(+), 2517 deletions(-)
[1] http://www.amazon.com/The-Art-Unit-Testing-Examples/dp/1933988274/ref=sr_1_1?s=books&ie=UTF8&qid=1338748288&sr=1-1
[2] http://wiki.buzztrax.org/index.php/Testing
2012/05 ========================================================================
More cruft removal this month. We dropped some more configure options (thanks
Adrian) and removed more old/unused code. The project also got the first commits
merged from Thomas - our GSoC student.
The pattern class had a boolean parameter to chose between command and data
patterns. I refactored that into a proper class hierarchy. The downside of that
is that we need more casts now :/
I also continued in the duplicated code cleanups. We have now a value-group,
that holds the pattern portion for a parameter-group. This way I could remove
lots of code from pattern and sequence. Finally I could also remove wire-pattern
itself. I am not totally happy with the extra code for loading and saving now,
but have some ideas here too.
The UI tests have a couple more helpers to synthesize events and saw a couple of
cleanups. The tests have been really useful for all the refactorings.
97 files changed, 4684 insertions(+), 5279 deletions(-)
2012/04 ========================================================================
I started hacking on the transport settings. The idea here is to have a generic
scheme for how to control playback (start, stop, seek) externally. This can be a
midi-controller, but also qjackcontrol or a MPRIS applet. The setting now show
the available modules and allow to enable master and slave mode as well as mode
specific settings. I could remove the combobox from the toolbar again.
As a next big thing I started to refactor a big chunk of duplicated code in
core. Machines have global parameters, per voice parameters and per incoming
wire parameters. Now we have a parameter-group class that deals with those.
I spend the rest of the month cleaning up the test suite and the autofoo setup.
On the latter I bumped the required versions. The policy now is to support the
linux distributions from about the last two years. This allowed me to remove
large chunks of conditional code. Unfortunately it is not easy to do that. The
easy part is to check what versions we require, by looking at the pkg-config
macros in configure.ac. Then we can also grep for conditional section in the
code:
find . \( -name "*.c" -o -name "*.h" \) -exec egrep -o "[A-Z]*_CHECK_VERSION\(.*\)" {} \; | sort | uniq
Now the tricky part is to figure what distributions ship. It is somewhat easier
for debian/ubuntu as they have pages like:
http://packages.debian.org/search?suite=all&arch=any&searchon=names&keywords=libgstreamer0.10-0
http://packages.ubuntu.com/search?suite=all§ion=all&arch=any&searchon=names&keywords=libgstreamer0.10
For fedora Company suggested to look at the spec files in git and iterate over
the branch names
http://pkgs.fedoraproject.org/gitweb/?p=gstreamer.git;a=blob;f=gstreamer.spec;hb=f17
For opensuse Vuntz suggested to use an osc query at which I failed misserably and
in the end checked the packages in the repo and iterated over the versions:
http://download.opensuse.org/distribution/12.1/repo/oss/suse/i586/
Anyone know better tricks? Please share them!
One more motivation for doing this is upcomming gsoc. If I am lucky to get a
student who will port buzztrax to gstreamer 1.0. We'll release a 0.7 of buzztrax
before we switch to the new gstreamer api.
212 files changed, 7954 insertions(+), 7778 deletions(-)
2012/03 ========================================================================
As a big leftover promise from my talk at the GStreamer conference in 2011 I
spend more time to understand latencies inside GStreamer. For plain playback the
latencies are not an issue, but for anything interactive, be it entering notes
or changing parameters while the song is playing, we want much lower latencies.
For the talk I did some measurements by having a pipeline with two branches -
src1 ! sink and src2 ! fx1 ! ... ! fxn ! sink. The fx elements where plain
volume elements. The branches where panned hard left and right. For the
experiment, I was pulling down the volume on the two sources down to 0 at the
same time and recoding the audio on the sink. Looking at the wave [1], one could
see the delay in the signal that went through the effect-chain. The longer the
effect-chain the larger becomes the delay. Don't misunderstand this, GStreamer
is properly handling A/V sync. The buffers that get mixed in front of the sink
have the same time stamps, the problem is that we have a lot more buffers
traveling the the effect-branch. This is because of the queue elements. In
buzztrax one can freely link generators to effects, effects to effects and
effects to sinks. This includes diamond shaped connections. Here we need queues
to not stall processing on one branch. It is sufficient for the queues to keep
only 1 buffer. Still even knowing the buffer duration, I could not tell a
formula to explain the measured delays.
This month I looked at the issue with a new idea. I wrote a small example [2]
that build pipelines close to what I have in buzztrax, but stripped of many
details. In this code I add buffer probed to all pads. The probe is comparing
the time-stamp on the buffer to the pipeline clock. This tells how early the
buffer is. Ideally we want buffers to be generated and processed as much in
time as possible. When generating audio one needs to configure audio-buffer
sizes on the source elements and two properties on the audio-sink - buffer-time
and latency-time. A good scheme is to use buffer-time = 2 * latency-time. That
configures the sink to have two audio-segments. Initially I also set the buffer
sizes on the source elements to have a duration of latency-time. Now one problem
with that is that we will have one buffer waiting on each queue. Thus if there
are two queues the actual latency is (n-queues + 1) * latency-time. One way to
improve that a bit is to half the buffer sizes on the sources, then the 2nd
buffer is calculated when the first one is needed. As the first one won't be
sufficient to fill the gap, the calculation of the 2nd buffer is scheduled right
away. The disadvantage of this scheme is that one gets quite jittery latencies.
In the end I settled on finishing the subtick timing in buzztrax. Each tick will
have n subticks, where n is setup so that we get down to the desired latency.
So far I get nice low latency on all my machines (inlcuding a atom based
netbook).
We also ported more buzzmachines and have 49 machines right now. When porting we
often also fix bugs as gcc is quite good at warnings these days. Finally, the
machines now also install docs (where available).
In the UI I got rid of the GtkRuler copy again. The analyzer window now has own
code to draw the rulers. I think they look nice, a lot less noisy then the older
rulers [3].
[1] http://files.buzztrax.org/latencies/
[2] http://buzztrax.git.sourceforge.net/git/gitweb.cgi?p=buzztrax/buzztrax;a=blob;f=design/gst/latency.c;hb=HEAD
[3] http://wiki.buzztrax.org/images/e/e8/Bt-edit-0.7.0-01.png
62 files changed, 1957 insertions(+), 1844 deletions(-)
2012/02 ========================================================================
The first big change after releasing 0.6 was to move from svn to git.
SourceForge offers git since a while, but does not provide any tips how to do
the transition. Fortunately it is a popular topic though. I used svn2git for the
main conversion. I fixed the author tags from svn commit messages (Patch-by:)
manually using git rebase -i as I could not get a filter-branch script for it to
work. A few times gitk got confused and I had to remove my .git/gitk.cache, one
symptom are missing tags. I updated the enlistments on ohloh and tweaked the git
hooks to have the same functionality as before.
A first code wise change was to move the bsl module into the buzztrax one. It is
a small module for the buzztrax song-loader plugin and it is not needed if you
don't want to load buzz songs. But it is small and has no further dependencies
and thus it is easier to just include it. Especially as we plan to add other
loaders in the coming cycle(s).
In the editor I bumped the required gtk version to get rid of some #ifdef and be
able to use newer API. I replaced the ruler widgets in volume and panorama
popups with with scale markers. Those look nicer and take the scale handle size
into account. Unfortunately they were almost untested. I made the needed patches
for gtk-2-24, gtk-3-2 and gtk-HEAD [1],[2]. I could also made workarounds for
the issue for the time being. So for the time being, don't use inverted ranges
on your scales and don't use an adjustment with fractions (use 0 .. 100 instead
of 0.0 to 1.0).
Most of the work went in the the interaction controller. The controller
assignment in the UI is a bit more discoverable (content menu not only on main
widgets, but also on the label and value label). Controllers can be assigned to
combo-boxes too (mapped to enums). We have controllers for note-on midi messages
and the velocity that comes with it now.
The other bigger change is that we now have persistent audio sessions (right now
only enabled for jack). We're basically keep the sink alive across songs and
also keep it in a resource allocated state. This gives a little speedup on the
playback startup, but the main motivation was to allow to configure linkage of
buzztrax with other jack client in qjackcontrol. This is also an enabler for
transport sync support. I have landed initial support for this in gstreamer-git.
There were also a few smaller changes for user feedback on docs and new tips.
The design folder got more experiments.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=667598
[2] https://bugzilla.gnome.org/show_bug.cgi?id=667590
485 files changed, 2638 insertions(+), 2033 deletions(-)
2012/01 ========================================================================
Finally after a long time, I managed to release a 0.6 of buzztrax. So far only
one regression was found and bml-0.6.1 was released to fix it.
A few things happened before the release still. At first after updating my
distro, I made a lot of changes to avoid deprecated gtk+ api. For now we ship
a copy of the ruler widget (that got removed in 3.0). The internal ruler widget
is a lot saner than the upstream one too.
Another big change was to move from string parameter for notes to an enum. This
is faster and lets us do things like blending of note ranges or transposing.
I also made quite a few bug-fixes - laspa effects work again, fluidsynth fixes,
etc.
Now I look forward to a lot of new changes in 0.7.X.
2011/12 ========================================================================
Over the last 2 month I did quite a bit of work on the GStreamer side. Right now
we're working on 0.10 and 0.11 in parallel. I worked on the audiovisualizers and
opencv elements in 0.10. I added a freeverb port to 0.10. In 0.11 I updated the
controller susbsystem. If is now a lot easier to use and faster too. I also
ported the audiovisualizers and fixed a few elements here and there.
In the beginning of November I gave a seminar about mobile multimedia using
GStreamer. For that I wanted to have a few more examples. I have been polishing
some examples in GStreamer and adding some more (simple audio-mixer with xfade).
One example is a nice showcase for how easy you can do some things. It is called
tonematrix [1]. It is 497 lines of c, including comments, a GTK ui with an own
widget and the whole GStreamer handling. The toy supports different sounds,
different speeds and different scales.
Buzztrax allows live control of audio elements. Right now can use midi and hid
devices. The software that exposes the wiimote as a hid device uses uinput. This
is a kernel device with a simple api that allows user-space apps to create hid
devices. I wrote a small toy (280 lines of c) that can use different GStreamer
pipelines containing analyzer elements and map the detected features to virtual
joystick controls [2]. The simplest example is to map the loudness of the
mic-input to the x-axis. A similar example is to map the brightness of the
camera input to a joystick axis. Then you can control e.g. the filter-cutoff of
a synthesizer by shielding the light from the camera sensor. Now the fun starts
with the recently improved facedetect plugin in GStreamer. This can not only
detect the faces, but also the positions of eyes, nose and mouth within the face.
Unfortunately the detection is not very stable when drawing faces. The idea here
obviously is to make grimaces and control sound with that. A very expressive
performance :)
I also spend a lot of time to track down issues with dynamic linking. A few more
fixes are done on buzztrax side and GStreamer side. I think on the buzztrax side
things are good for a release. Everything is reviewed (docs, demo-songs, ...)
and make distcheck passes :)
57 files changed, 4323 insertions(+), 374 deletions(-)
[1] http://buzztrax.svn.sourceforge.net/viewvc/buzztrax/trunk/buzztrax/design/gst/tonematrix.c?revision=3655&view=markup
[2] http://buzztrax.svn.sourceforge.net/viewvc/buzztrax/trunk/buzztrax/design/input/gstinput.c?revision=3655&view=markup
2011/10 ========================================================================
This month I focused on testing for the next release. My free time for the
project was a big short anyway, as my family move to our new home and I had
quite some janitorial work to do.
One lesson learned for the start. Some time ago I had problems with tests going
crazy and eating memory. This can bring down the whole system which is bad. My
solution at this time setrlimit(RLIMIT_AS,&rl) to cap the memory usage. While
that works, that is also one way to shoot yourself in the foot. I was wondering
why tests that work flawlessly on 32bit systems fail with "mmap() failed:
Cannot allocate memory". Doh, 64bit platforms need more memory than 32bit ones.
Now I raised the limits unconditionally and everything is working again. Would
be good to check the difference to see how much more memory 64bit apps that in
average - its not twice as much I think.
I did lots of valgrinding and obviously found and squashed a few leaks. It would
be really nice if each library would ship a suppression file as part of the dev
package. The file could be installed to /usr/lib/valgrind/<package>.supp. The
pkg-config file would have two variables: 'vg_supp' pointing to the suppression
file and 'vg_env' setting extra environment variables easing valgrinding. This
way one could just collect these from the libraries an application uses and be
done. GObject based libs could suppress their singletons to improve the valgrind
experience.
From time to time potential users show up on irc and get scared when I ask them
to build the latest version from the sources. In the need for having an easy way
to offer testers and translators the latest version, I took a look at glick [1].
It is actually pretty straight forward. The resulting glick files where
initially somewhat large, but after pruning development files, they are just
about 6 Mb. I have two of them online - one for 32bit [2] and one for 64bit [3]
systems. How to use them? Just download and run them - they don't install
anything. The only downside I can see so far is, that the glick bundle would use
the same settings as the properly installed one, which could be harmful if
different versions are run. Also the path to the example songs in the bundle is
somewhat cryptic - /proc/self/fd/1023/share/buzztrax/songs :/. Having better
desktop integration of such bundles would be great too, but less see how glick
evolves.
50 files changed, 836 insertions(+), 373 deletions(-)
[1] http://people.gnome.org/~alexl/glick/
[2] http://www.hora-obscura.de/~ensonic/buzztrax.x86_32.glick
[3] http://www.hora-obscura.de/~ensonic/buzztrax.x86_64.glick
2011/09 ========================================================================
After lots of changes I have switched the code permanently to the new sequence
model. It saves about 170 lines of code in the sequence-page source. There is
some potential to save more though.
I also did more work on state persistence. A song now contains more information
(selected machines, pattern, options) and these things are restored when loading
a song.
Another good change was moving the song-unsaved flag from the song
(core-library) to the edit application. This make the core library more light-
weight. The editor application can now determine whether there is something to
save by combining the unsaved-flag and the undo/redo stack. The unsaved-flag is
still needed as I feel not everything needs to go to the undo/redo stack (like
selecting a machine). Undo/redo looks quite complete now. I found a solution for
my last issue, although I am still not entirely happy with it.
I also made a few startup time improvements. Found a weird issue with the
interaction-controller library probing joystick devices. One ioctl on joy
devices for hdaps devices is hanging for quite a bit.
Finally I did a huge cleanup on or somewhat uncommon header file setup. We
always had a header declaring the types and one the methods. This helped with
include conflicts. But now we have 50% less files to care and I just needed 2
forward declarations.
Again several bugs were fixed. I will check remaining reported bugs and hope that
everything is fine to consider releasing 0.6.
253 files changed, 27205 insertions(+), 26602 deletions(-)
2011/08 ========================================================================
Another month with good progress. I've started with the undo/redo parts in the
sequencer view. Most of the edits are handled now. I am still stuck with one
problem though. So far the order of signal handler on object removal did not
matter. Now it does :/ There are things that when they get removed remove other
things. And that causes chains of modificatins that in the change log would
overwrite (shadow) the save data. Not yet sure how to solve that. I'll probably
confront someone at the desktop summit [1] with the problem over some beer in
the hope that I find a solution while I am explaining the issue :) As a good
side effect of the undo/redo work, I could remove the warning dialogs that I was
showing when removing things. Makes the editor more pleasant to use.
During my july trip to mountain view I brought two cheap midi controlers -
korg nanokontrol [2] and nanokeys 2 [3]. The nanokeys2 is not so nice, but the
nanokontrol seems to be okay. Unfortunately I didn't notice is is the old model,
the nanokontrol 2 [4] has more keys. I have played quite a bit with the nanokontrol
in buzztrax. Found and fixed a few bugs. One thing I definitely needed to do is
to store the keys one has trained. Thanks to my long train journeys between
munich and leipzig these days, that got implemented. For the nanokeys I need to
still do a couple of things and those will have to wait for the next version.
As I was blocked on the undo/redo I did more small mini-songs. As usual found a
couple of bugs. Buzztrax stores timestamps in the song (like when it was created
and when it was saved the last time). When closing a song with changes it warns
you about loosing the changes for the last n hours/minutes. Thas was completely
off if one loads a song and makes some changes. I need to set the last-saved to
the time of the first change. A few other bugs were related to 64bit arch and
using wrong int types in varargs functions. I also made some ui improvements.
The settings hide more unusable audiosinks (apexsink, sfsink), especially
probing apexsink caused long delays as I don't have the hardware for it.
One issue that I had no good explanation for but that was quite apparent when
doing demos was small breaks when the song loops. Especially at the first loop
it caused a bad glitch and later it sometimes played a bit too much or skipped
something when wrapping around. I had made some test apps for it, but could not
reproduce it there so far. Finally I looked at it again and found a small self-
contained testcase that was reproducing it. On that base I could narrow it down
to a combination of two gstreamer elements causing it. Still it was not straight
forward to fix it, after all it is not crashing or such. I decided that the only
way forward was to get a good picture of what is happening and verifying the
events step by step. Voila, we now have a improved gst-tracelib and a gnuplot
script for plotting event over time. Would be nice to have a more interactive UI
for gnuplot though. I filed a bug [5] and put the data there, if you are curious
about the graphs. After some more nights I found the issue and the fix for the
adder plugin is now upstream. A simillar change needs to be done for the
videomixer elements (will look into that soon).
[1] http://www.desktopsummit.org
[2] http://www.amazon.de/Korg-NANOKONTROLB-nanoKONTROL-schwarz/dp/B001J8LJWK
[3] http://www.thomann.de/gb/korg_nanokey_2_black.htm
[4] http://www.thomann.de/gb/korg_nanokontrol_2_black.htm
[5] http://bugzilla.gnome.org/show_bug.cgi?id=655204
43 files changed, 2779 insertions(+), 496 deletions(-)
2011/07 ========================================================================
This month I made great progress. I have been making several small demo songs
and found+fixed quite many bugs and glitches along with that.
After a little break I took up undo/redo work and could make good progress. Now
also pattern property changes (name and length) are tracked. In the sequence the
boilerplate code is there, single edits, track and property changes are handled.
In the machine view the initial machine position is tracked in the change-log.
In the middle of the month I did doc updates - api docs had some stuff missing
and the user help finality has more beef and short-cut tables for all the
keyboard accelerators.
OmniMancer on irc gave me some good first perspective usage experience. I added
a blacklist filter to hide gstreamer elements from the menu that are known
to be not useful for buzztrax (e.g. dtmfsrc). Also some machines used GTypes not
yet supported by the UI - this is now fixed. With that came some fixes in
pattern editing (blending parameters wasn't working in all cases). I also added
a flip operation to the patterns. Also to make a few things easier for new users
I added two items to help menu - file a bug and goto irc. The later fires up the
freenode webirc as xdg-open seems to be unable to launch e.g. xchat for irc://
urls.
I have started to write the missing treemodel for the sequence view and used
that changed to overhaul a few things. Even without the new model its quite a
bit faster as we do less model rebuilds (e.g. when expanding the length). Also
the row-shading code is simpler and with that the cell-data functions. Finally
the pattern usage tracking is now using a hashtable instead of rescanning the
sequence.
With all those changes comes a bag of bug fixes - I'll skip listing them here -
it is all in the change log. Also I did a bit of code cleanups and reorgs. Like
using macros for the GType handling to save lines of code. Or bump the gtk+
version (2.10.12) to get rid of fallback code. Finally I rechecked a glib bug
regarding mime-matching. It's fixed since a while, but I still saw it, as the
.recently-used.xbel file had the wrong mime type from the time when glib had the
bug in there. Maybe it would be good to trim that file from time to time. Imho
it should also be in $XDG_CACHE_DIR and not $HOME, but that is a different
story.
48 files changed, 2712 insertions(+), 1250 deletions(-)
2011/06 ========================================================================
In the beginning of the month I finished the new treeview models. There were a
couple of corner cases I did not handled yet. I did some thinking about the
remaining model, but did not yet write any code for it. Instead I did some code
review of the whole project leading to numerous small cleanups and fixes. I also
got rid of some holes in the api docs.
Otherwise I worked more on GStreamer and gtk-doc. In GStreamer I mostly hacked
on a baseclass for audio-visualizers which is now in gst-plugins-bad (together
with 4 elements using it).
There are some other reasons for not having so much time to hack on, of which I
will shortly speak about :)
32 files changed, 1848 insertions(+), 444 deletions(-)
2011/05 ========================================================================
After last month spectrum analyzer work, I also looked at the volume meters
again. Handling the updates is a bit tricky as I need to sync them to the audio
playback. Now I have optimizations in place to skip updates when the meter is
zero or maxed and has not changed. This is actually quite often the case.
I also fixed a small UI glitch; song-io plugins did not tell so far whether they
support saving and/or loading. Thus one could end up selecting a format and then
getting an error. Now one will see only the formats that plugins can handle.
Finally I got around catching up on the docs too. Now all dialogs have some docs
including screenshots.
One refactoring I was actually considering to push for after the next release was
getting rid of the GtkListStores and use real GtkTreeModels instead. The
disadvantage of a ListStore is that it is static, if the underlying object is
dynamic one needs to manually synchronize it. This enlarges the code and also the
duplicated data storage uses memory. Writing own models was in the end not so
difficult, it is quite some boilerplate code though. The first one I wrote is a
object-list-model. It allows to bind object-properties to model columns. If e.g.
a field changes, the model notifies and the view updates [1]. The whole thing
could become more generic if we would have an iterator interfaces and the
collection types (list, array, ..) would be gobjects implementing the iface.
Well, I am not the first to notice that :) [2]. Next I made 2 specialized models
and started to take them into use. As a bonus e.g. the machine model provides a
nice logical sorting. One more model to implement and switch to.
72 files changed, 6268 insertions(+), 1250 deletions(-)
[1] http://buzztrax.svn.sourceforge.net/viewvc/buzztrax/trunk/buzztrax/src/ui/edit/object-list-model.c?revision=3350&view=markup
[2] http://pvanhoof.be/blog/index.php/2009/08/17/treemodel-zero-a-taste-of-life-as-it-should-be
2011/04 ========================================================================
I have been refactoring GStreamer's spectrum analyzer. It is now working faster
and also allows to get per-channel results. For testing I updated buzztrax to
check if one has the new version and if so show per channel graphs. While
hacking on the analyzer graphs I have also refactored the code, so that now it
is possible to probe the final output as well.
I spend the bigger part of the month on the tests again. I had an unref too
much somewhere. Even after all the work in refdbg this is still difficult to
track down. Eventually I found it and now all tests are green.
51 files changed, 2549 insertions(+), 1817 deletions(-)
2011/03 ========================================================================
I was testing buzztrax a lot on my MeeGo netbook this month. As screen space is
more precious on netbooks I was running it often in fullscreen mode and noticed
that some windows seem to not open. When leaving full screen the windows
appeared. Somehow they opened behind the main window. I looked over all child
windows and dialogs and cleaned up the handling with a helper method doing:
gtk_window_set_transient_for(window, main_window);
gtk_window_set_destroy_with_parent(window, TRUE);
On my desktop it works fine on the netbook the problem still happens :/ No idea
right now. As a good side effect I ensured that all dialogs have a properly set
default response.
I was also running the performance tests and did some oprofiling. I knew already
that my data-fixup code for buzzmachines caused quite some overhead. It is
handling denormals and marking full zero buffers as empty. I now added code that
sets the FPU on x86 machines to DAZ|FZ mode from the application and disable the
fixup code. On my netbook my 11 min benchmark song renders in about 1 min
instead of 1:20 min before. On my desktop most of the change are hard to
measure as it already only takes 5 seconds :). Anyway the oprofile runs confirm
the speedup. The code disappeared from the top 20.
The pattern editor widget becomes slow when getting large. Some text drawing
operations look expensive. For a start I ported the whole widget to use cairo,
but that does not take care of the slowness. After more measurements it becomes
clear that I need to rework this more. I need to render it offscreen and reply
to expose events by copying pixels.