9
I Use This!
Very Low Activity

News

Analyzed 1 day ago. based on code collected 2 days ago.
Posted over 11 years ago
gtk-doc Just released gtk-doc 1.20 with lots of bugfixes and feature request implemented (32 tickets closed). If you are a developer, fetch it and rebuild your docs - I hope you like the new look! The biggest feature is the large improvement over ... [More] the rudimentary markdown support gtk-doc had - thanks to William Jon McCann for the contributions. Take a look at the manual to learn about the new syntax. We chose markdown, so that the syntax looks good in the sources and you can already go ahead using it. If someone builds with an older gtk-doc things might show up as is, but thats not the end of the world. [Less]
Posted over 11 years ago
gtk-doc Just released gtk-doc 1.20 with lots of bugfixes and feature request implemented (32 tickets closed). If you are a developer, fetch it and rebuild your docs - I hope you like the new look! The biggest feature is the large improvement over ... [More] the rudimentary markdown support gtk-doc had - thanks to William Jon McCann for the contributions. Take a look at the manual to learn about the new syntax. We chose markdown, so that the syntax looks good in the sources and you can already go ahead using it. If someone builds with an older gtk-doc things might show up as is, but thats not the end of the world. [Less]
Posted almost 12 years ago
sndfile plugin for gstreamer 1.X A merry christmas to everybody. As a little present for musicians, I started a rewrite of the sndfile plugin that had not been ported from gstreamer-0.10. The new version will not be consist of sfsrc and sfsink, but ... [More] instead of sfdec and sfenc. For now sfdec exists, it can read a bunch of formats that we did not have support in gstreamer so far - xi, sds, 8svx/16sv, w64, ... and it works with playbin and co. I'll need to collect more test files to test all features. I'll also write the encoder/muxing part next. libsnd file has good support for audio files that are used as instruments. There are quite a ew things that I can't map to gstreamer yet: base note - could be a tag loops - could be a special toc edition, but that sounds like a little abuse, some form of edit-list support would probably be better envelopes (e.g. a volume envelope) Maybe I can start with some element-messages for now. [Less]
Posted almost 12 years ago
sndfile plugin for gstreamer 1.X A merry christmas to everybody. As a little present for musicians, I started a rewrite of the sndfile plugin that had not been ported from gstreamer-0.10. The new version will not be consist of sfsrc and sfsink, but ... [More] instead of sfdec and sfenc. For now sfdec exists, it can read a bunch of formats that we did not have support in gstreamer so far - xi, sds, 8svx/16sv, w64, ... and it works with playbin and co. I'll need to collect more test files to test all features. I'll also write the encoder/muxing part next. libsnd file has good support for audio files that are used as instruments. There are quite a ew things that I can't map to gstreamer yet: base note - could be a tag loops - could be a special toc edition, but that sounds like a little abuse, some form of edit-list support would probably be better envelopes (e.g. a volume envelope) Maybe I can start with some element-messages for now. [Less]
Posted over 12 years ago
buzztrax ui porting 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 ... [More] 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(-) [Less]
Posted over 12 years ago
buzztrax ui porting 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 ... [More] 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(-) [Less]
Posted over 12 years ago
buzztard is now buzztrax 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 ... [More] project - buzztard is now called buzztrax. The homepage with the wiki and wordpress already got moved. The renamed codebase is online at github. 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. 56 files changed, 715 insertions(+), 631 deletions(-) [Less]
Posted over 12 years ago
buzztard is now buzztrax 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 ... [More] project - buzztard is now called buzztrax. The homepage with the wiki and wordpress already got moved. The renamed codebase is online at github. 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. 56 files changed, 715 insertions(+), 631 deletions(-) [Less]
Posted over 12 years ago
buzztard & gstreamer hackfest 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 ... [More] 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(-) [Less]
Posted over 12 years ago
buzztard & gstreamer hackfest 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 ... [More] 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(-) [Less]