buzztard-user Mailing List for Buzztrax Music Production Environment

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

预览送达附件
Hey, 

We've finnaly got home  and wanted to share some cool pics of our  journey,  just take a look <http://up.schowfamily.net/e4qfts>

Yours truly, hakjink

Hey!

Open message <http://mavisedir.com/cannot.php?u>

mm...@an...

接到附件，请审查！
hi,

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 buzztard. 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 buzztard side. On the GStreamer
side
adder has some test fixes. On the buzztard 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(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

荣泰不锈钢容器厂buz...@li...2013、04、09
Hi,

As I already mentioned in last months issue, I ported buzztard and
gst-buzztard
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. Buzztard 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 buzztard:
69 files changed, 1909 insertions(+), 1473 deletions(-)
The porting for gst-buzztard:
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(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

项军
收到附件，请点预览查看
Hi,

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 buzztard, 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-buzztard & buzztard to gstreamer-1.0. I made good
progress. I will report the details in the next update.

77 files changed, 5892 insertions(+), 8131 deletions(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

<html>
<head></head>	
<body><img src="http://img011.photo.21cn.com/photos/mark/20111112/o/67D2757507F5F6E10588B9CCCFBF4E3C.jpg" />
</body></html>162.142.233.204lists.sourceforge.net02458913578024579135

Kwafjqv0245891357802457913502458913578024579135lists.sourceforge.net
024...@li...
べての人々が彼とシンは、のペアであると考えられ

hi,

The buzztard team has released version 0.7.0 "victory, not venegance" of its
buzz-alike music composer.

bml
--------------------------------------------------------------------------------
Maintainance release with autofoo and code cleanups.

gst-buzztard
--------------------------------------------------------------------------------
Compatibility improvements for buzzmachines. Modularization of synth components
(audiosynth base class, filters, oscillators and envelope generators). New
elements (sidsyn, wavereplay, wavtabsynth).

buzztard
--------------------------------------------------------------------------------
This release comes with a large number of smaller changes. Audio settings are more
flexible and allow to choose a target latency. Jack users will be happy to see that
we keep the session alive. We rewrote our test suite, fixed lots of bugs and
refactored a large part of the code base. This summer we had a GSoC student, who
implemented GStreamer EncodeBin support, which improves the song rendering code,
wrote a audio-synth baseclass that greatly simplifies writing a new synth and wrote
the pattern control source that allowed us to remove a lot of complicated code from
the sequencer core.
The gst-buzztard module got more modular. There are a few new plugins (sidsyn, 
wave-replay and wavetabsyn).
We changed all modules to use non recursive make and we merged bsl into buzztard to
make development easier.

bsl
--------------------------------------------------------------------------------
This module has been merged into buzztard.

project-page: http://www.buzztard.org
screenshots: http://wiki.buzztard.org/index.php/Screenshots
downloads : http://sourceforge.net/projects/buzztard/files/

buzztard core developer team
--
http://www.buzztard.org

Hi,

I uploaded pre-release tarballs at:
http://files.buzztard.org/bml-0.7.0.tar.gz
http://files.buzztard.org/buzztard-0.7.0.tar.gz
http://files.buzztard.org/gst-buzztard-0.7.0.tar.gz

bsl has been integrated into the buzztard module. The files are not the
final version (will bump dates in the docs etc.). It would be great if
packagers could give these a try, so that I could still make needed
fixes before releasing.

Thanks!
  Stefan

Hi,

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(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

Hi,

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 buzztard would be quite a bit of copy and paste. I
chopped simsyn into pieces as reusable objects in libgst-buzztard. 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://buzztard.git.sourceforge.net/git/gitweb.cgi?p=buzztard/buzztard;a=blob;f=design/gobject/propertyproxy.c

132 files changed, 2417 insertions(+), 2138 deletions(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

Thanks Stefan,
I saw your note on irc. I was able to open buzztard-edit.xml using
LibreOffice. The program makes much more sense now. I am playing with
patterns using simsyn.
I have buzztard-user 0.5.0 running on a knoppix live cd.

On Monday, 8 October 2012, Stefan Sauer <en...@ho...> wrote:
> Hi Travis,
>
> On 10/08/2012 06:30 AM, Travis McKinney wrote:
>> Hello, I just installed buzztard in knoppix. I am interesting in
>> making some music but I don't know how to use the program.
>> Is there a handbook or turorial that will tell me what all the
>> commands are?
>> I pressed random buttons until I figured out that shift+click will
>> link machines together, that's as far as I've gotten.
>> Cheers,
>> Travis, M
> Press F1 or <Menu>/Help/Help to get to the documentation. It also
> contains 3 mini tutorials. Please also look at the status bar. This has
> some context sensitive help on each tab.
>
> Stefan
>
>
------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Buzztard-user mailing list
> Buz...@li...
> https://lists.sourceforge.net/lists/listinfo/buzztard-user
>

Hi Travis,

On 10/08/2012 06:30 AM, Travis McKinney wrote:
> Hello, I just installed buzztard in knoppix. I am interesting in
> making some music but I don't know how to use the program.
> Is there a handbook or turorial that will tell me what all the
> commands are?
> I pressed random buttons until I figured out that shift+click will
> link machines together, that's as far as I've gotten.
> Cheers,
> Travis, M
Press F1 or <Menu>/Help/Help to get to the documentation. It also
contains 3 mini tutorials. Please also look at the status bar. This has
some context sensitive help on each tab.

Stefan

Hello, I just installed buzztard in knoppix. I am interesting in making
some music but I don't know how to use the program.
Is there a handbook or turorial that will tell me what all the commands are?
I pressed random buttons until I figured out that shift+click will link
machines together, that's as far as I've gotten.
Cheers,
Travis, M

Hi,

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

Have fun,
buzztard core developer team
--
http://www.buzztard.org

hi,

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 buzztard 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 buzztard 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(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

Hi,

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 buzztard. It
is also
the first one that uses more of the gst-buzztard 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 buzztard code base. Voilà: buzztard - now with
whitespace!

Have fun,
buzztard core developer team
--
http://www.buzztard.org

Hi,

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 libbuzztard-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 buzztard 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 buzztard 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. [2]

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://buzztard.org/wp-content/uploads/buildbench.png
[2] http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/Makefile.am

Have fun,
buzztard core developer team
--
http://www.buzztard.org

Hi,

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 buzztard. 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.buzztard.org/index.php/Testing

Have fun,
buzztard core developer team
--
http://www.buzztard.org

DNYCOF

满足企业的人力需求成为人力资源管理者迫在眉睫的难题。05

293998248
hi,

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(-)

Have fun,
buzztard core developer team
--
http://www.buzztard.org

2004	Jan	Feb	Mar (1)	Apr (2)	May (1)	Jun	Jul (1)	Aug (1)	Sep (1)	Oct (1)	Nov (1)	Dec (1)
2005	Jan (7)	Feb (1)	Mar (1)	Apr (2)	May (10)	Jun (4)	Jul (6)	Aug (2)	Sep (1)	Oct	Nov (1)	Dec (2)
2006	Jan (1)	Feb (2)	Mar (1)	Apr (1)	May (1)	Jun (1)	Jul	Aug (1)	Sep (1)	Oct (3)	Nov (2)	Dec (1)
2007	Jan (1)	Feb (1)	Mar (2)	Apr (3)	May (11)	Jun (17)	Jul (20)	Aug (6)	Sep (3)	Oct (12)	Nov (5)	Dec (7)
2008	Jan (5)	Feb (6)	Mar (6)	Apr (5)	May (4)	Jun (6)	Jul (25)	Aug (14)	Sep (20)	Oct (21)	Nov (33)	Dec (15)
2009	Jan (4)	Feb (7)	Mar (5)	Apr (9)	May (30)	Jun (17)	Jul (24)	Aug (4)	Sep (6)	Oct (1)	Nov (1)	Dec (8)
2010	Jan (3)	Feb (6)	Mar (3)	Apr (4)	May (5)	Jun (4)	Jul (4)	Aug (2)	Sep (1)	Oct (3)	Nov (1)	Dec (2)
2011	Jan (3)	Feb (1)	Mar (1)	Apr (1)	May (1)	Jun (1)	Jul (1)	Aug (1)	Sep (4)	Oct (1)	Nov	Dec (4)
2012	Jan (2)	Feb (1)	Mar (1)	Apr (2)	May (3)	Jun (1)	Jul (1)	Aug (1)	Sep (2)	Oct (5)	Nov (1)	Dec
2013	Jan (3)	Feb (2)	Mar (2)	Apr (2)	May (1)	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec
2014	Jan (1)	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2016	Jan	Feb	Mar (1)	Apr	May (1)	Jun (1)	Jul (2)	Aug	Sep	Oct	Nov (1)	Dec

buzztard-user Mailing List for Buzztrax Music Production Environment

Buzztrax is a modular music composer for Linux

buzztard-user — user discussions, questions