Re: [LAD] Is TerminatorX development stalled?
On 12/30/2009 06:52 PM, Eric Shattow wrote: As an alternative to terminatorX, the Mixxx project has progressed to the point where you can do a lot of what tX does, just add a sampler. The novelty of tX was mostly in the support of mouse-as-controller, audio effects, and looping samples. Support for hot cues and looping is under active development in Mixxx - check out the Mixxx 1.8 pre-release. For djing with turntables you should also look into xwax. Mixx and xwax share the same turntable codebase but iiuc xwax has more attention focused on the turntable aspect and you should use an external mixxer, whereas mixx is more focused providing an ui environment for mixing. Either way they both work very well for djing and scratching. Patrick Shirkey Boost Hardware Ltd On Tue, Dec 29, 2009 at 11:28 AM, Patrick Shirkey pshir...@boosthardware.com mailto:pshir...@boosthardware.com wrote: On 12/30/2009 05:21 AM, gerald mwangi wrote: Hello Guys, i'm new to this mailing list. I just wanted to know if TerminatorX development is stalled. The last version is 3.82 since 2 years or so. Or is there another Program of the sort and under development. Please let me know, maybe i'll pick up development of TerminatorX. Gerald You might find that the development version has been updated more recently than the official release version. Best to get in touch with Alexandre Koenig directly if you want to contribute. He is a friendly chap. Cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org mailto:Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org mailto:Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
On 12/30/2009 06:37 AM, hermann wrote:
Am Mittwoch, den 30.12.2009, 01:18 +1100 schrieb Patrick Shirkey:
Hi,
I have some code in gtk2 that is leaking and I can't fix it. Over the
past two nights I have managed to get the leak down from 200MB/minute to
200MB/10 minutes but I can't get rid of it completely. It's annoying
because it increments in 200MB blocks so I have to wait for up to 10
mins to see if it is fixed or not. I have tried valgrind but it doesn't
really like jack and did not give me any useful output. I have traced
the leak through normal debugging and have verified that it does not
happen if I disable this offending code.
This code is run in the widgets realize event and the event is triggered
every 500ms.
And when you use style-font_desc, you could move the font discription
to init, and change only the text every 500ms.
Thanks for your ideas on nailing this bug.
Below is what I have come up with now thanks to your input. I am still
seeing a leak after about 8 mins. The slightly annoying thing to me is
that it increments in a block of 200MB and not gradually. It's as though
pango/gtk is requesting an additional block of memory cache to fill up
each time.
The widget class is a custom class called gtkmeter.c which doesn't have
an internal font description or text value. The code below is for
writing the notch values onto the gtkmeter so this method is called
multiple times for each redraw of the widget. There are 16 instances of
the widget with 11 notch values on each one making a total of 176
requests to this method every 500ms. At 200MB/8 mins that is about 20kb
leak per redraw or approx 120 bytes per request.
db is a float value passed in the method variables.
+++
PangoLayout *pl;
PangoRectangle rect;
GtkStyle *style = gtk_widget_get_style(widget);
char text[3];
snprintf(text, 3, %.0f, fabs(db));
pl = gtk_widget_create_pango_layout(widget,text);
pango_layout_get_pixel_extents(pl, rect, NULL);
x = pos - rect.width/2 + 1;
y = width/2 - rect.height / 2 + 1;
if (x 1) {
x = 1;
} else if (x + rect.width length) {
x = length - rect.width + 1;
}
gdk_draw_layout(widget-window, widget-style-black_gc, x, y, pl);
last_label_rect-width = rect.width;
last_label_rect-height = rect.height;
last_label_rect-x = x;
last_label_rect-y = y;
g_object_unref (pl);
+++
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
Am Mittwoch, den 30.12.2009, 22:50 +1100 schrieb Patrick Shirkey:
Thanks for your ideas on nailing this bug.
Below is what I have come up with now thanks to your input. I am still
seeing a leak after about 8 mins. The slightly annoying thing to me is
that it increments in a block of 200MB and not gradually. It's as though
pango/gtk is requesting an additional block of memory cache to fill up
each time.
The widget class is a custom class called gtkmeter.c which doesn't have
an internal font description or text value. The code below is for
writing the notch values onto the gtkmeter so this method is called
multiple times for each redraw of the widget. There are 16 instances of
the widget with 11 notch values on each one making a total of 176
requests to this method every 500ms. At 200MB/8 mins that is about 20kb
leak per redraw or approx 120 bytes per request.
db is a float value passed in the method variables.
+++
PangoLayout *pl;
PangoRectangle rect;
GtkStyle *style = gtk_widget_get_style(widget);
char text[3];
snprintf(text, 3, %.0f, fabs(db));
pl = gtk_widget_create_pango_layout(widget,text);
pango_layout_get_pixel_extents(pl, rect, NULL);
x = pos - rect.width/2 + 1;
y = width/2 - rect.height / 2 + 1;
if (x 1) {
x = 1;
} else if (x + rect.width length) {
x = length - rect.width + 1;
}
gdk_draw_layout(widget-window, widget-style-black_gc, x, y, pl);
last_label_rect-width = rect.width;
last_label_rect-height = rect.height;
last_label_rect-x = x;
last_label_rect-y = y;
g_object_unref (pl);
+++
Patrick Shirkey
Boost Hardware Ltd
We use also level meters in guitarix and jcgui, what we do to create the
notch scale is, move it to a background box, a simple hbox, witch we
connect with a expose call. This way the values and scale only redraw
when needed. This is the call we use:
gboolean meter_scale_expose(GtkWidget *wi, GdkEventExpose *ev, gpointer
user_data)
{
cairo_t *cr;
/* create a cairo context */
cr = gdk_cairo_create(wi-window);
cairo_set_font_size (cr, 7.0);
double x0 = wi-allocation.x+1;
double y0 = wi-allocation.y+2;
double rect_width = wi-allocation.width-2;
double rect_height = wi-allocation.height-4;
int db_points[] = { -50, -40, -20, -30, -10, -3, 0, 4 };
char buf[32];
cairo_rectangle (cr, x0,y0,rect_width,rect_height+2);
cairo_set_source_rgb (cr, 0, 0, 0);
cairo_fill (cr);
cairo_pattern_t*pat =
cairo_pattern_create_radial (-50, y0, 5,rect_width-10,
rect_height, 20.0);
cairo_pattern_add_color_stop_rgb (pat, 0, 0.2, 0.2, 0.3);
cairo_pattern_add_color_stop_rgb (pat, 1, 0.05, 0.05, 0.05);
cairo_set_source (cr, pat);
cairo_rectangle (cr, x0+1,y0+1,rect_width-2,rect_height-2);
cairo_fill (cr);
for (uint32_t i = 0; i sizeof (db_points)/sizeof (db_points[0]);
++i)
{
float fraction = log_meter (db_points[i]);
cairo_set_source_rgb (cr, 0.12*i, 1, 0.1);
cairo_move_to (cr, x0+rect_width*0.2,y0+rect_height -
(rect_height * fraction));
cairo_line_to (cr, x0+rect_width*0.8 ,y0+rect_height -
(rect_height * fraction));
if (i6)
{
snprintf (buf, sizeof (buf), %d, db_points[i]);
cairo_move_to (cr, x0+rect_width*0.32,y0+rect_height -
(rect_height * fraction));
}
else
{
snprintf (buf, sizeof (buf), %d, db_points[i]);
cairo_move_to (cr, x0+rect_width*0.34,y0+rect_height -
(rect_height * fraction));
}
cairo_show_text (cr, buf);
}
cairo_set_source_rgb (cr, 0.4, 0.8, 0.4);
cairo_set_line_width (cr, 0.5);
cairo_stroke (cr);
cairo_pattern_destroy (pat);
cairo_destroy(cr);
return FALSE;
}
it draw a black box with light in the upper left corner, and a scale
with values draw in dark green over light green to red.
regardshermann
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
On Wed, Dec 30, 2009 at 7:47 AM, hermann brumm...@web.de wrote: We use also level meters in guitarix and jcgui, what we do to create the notch scale is, move it to a background box, a simple hbox, witch we connect with a expose call. This way the values and scale only redraw when needed. This is the call we use: ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the difference between the last drawn instance of the meter and the new appearance and only draw that the delta. this means that we often get away with drawing just a single row of pixels. http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/fastmeter.cc see the vertical_expose() and horizontal_expose() methods. Note that we are also using precomputed pixbufs and just blitting them. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
Am Mittwoch, den 30.12.2009, 07:57 -0500 schrieb Paul Davis: On Wed, Dec 30, 2009 at 7:47 AM, hermann brumm...@web.de wrote: We use also level meters in guitarix and jcgui, what we do to create the notch scale is, move it to a background box, a simple hbox, witch we connect with a expose call. This way the values and scale only redraw when needed. This is the call we use: ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the difference between the last drawn instance of the meter and the new appearance and only draw that the delta. this means that we often get away with drawing just a single row of pixels. http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/fastmeter.cc see the vertical_expose() and horizontal_expose() methods. Note that we are also using precomputed pixbufs and just blitting them. The LevelMeters we use are highly inspired ( an adaptation) by your Gtkmm2ext::FastMeter :-) just ported to Gtk+ http://guitarix.svn.sourceforge.net/viewvc/guitarix/trunk/src/GtkFastMeter.cpp?revision=435view=markup The expose call I postet here run only when init or redraw after hiden, and only the scale and notch values. regards hermann ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
On 12/30/2009 11:57 PM, Paul Davis wrote: On Wed, Dec 30, 2009 at 7:47 AM, hermannbrumm...@web.de wrote: We use also level meters in guitarix and jcgui, what we do to create the notch scale is, move it to a background box, a simple hbox, witch we connect with a expose call. This way the values and scale only redraw when needed. This is the call we use: ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the difference between the last drawn instance of the meter and the new appearance and only draw that the delta. this means that we often get away with drawing just a single row of pixels. http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/fastmeter.cc see the vertical_expose() and horizontal_expose() methods. Note that we are also using precomputed pixbufs and just blitting them. Thanks for the advice. It's a very cool approach to use except I'm working with C. I'm not sure I'm up for porting from c++ to c right now. I am taking a slightly different approach to the visual aspect as I have added a glassy bubble overlay and the notches sit on top of the overlay. The meters are redrawing under the overlay to give the effect of being inside a glassy tube. So basically I have to redraw the whole thing each time unless I change the code to use the above method. The meters by themselves don't add any noticeable load. Do you think this memory leak can be fixed without having to completely redo the class to use precomputed bixbufs while porting from c++ to c? Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
Hello Patrick et al, I ported the ardour fast meters from C++ to C. Look into guitarix's code (GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it is very CPU friendly, the algorithm focusing only on the deltas from one event to the next. Hermann took care of the layout and that's what he was talking about when he mentioned something about the box_expose function. Paul, I mentioned your name and ardour in the guitarix header file. I hope this is fine. J. --- On Wed, 12/30/09, Patrick Shirkey pshir...@boosthardware.com wrote: From: Patrick Shirkey pshir...@boosthardware.com Subject: Re: [LAD] memory leak assistance To: Linux Audio Developers linux-audio-dev@lists.linuxaudio.org Date: Wednesday, December 30, 2009, 8:39 AM On 12/30/2009 11:57 PM, Paul Davis wrote: On Wed, Dec 30, 2009 at 7:47 AM, hermannbrumm...@web.de wrote: We use also level meters in guitarix and jcgui, what we do to create the notch scale is, move it to a background box, a simple hbox, witch we connect with a expose call. This way the values and scale only redraw when needed. This is the call we use: ardour's Gtkmm2ext::FastMeter optimizes even more. we compute the difference between the last drawn instance of the meter and the new appearance and only draw that the delta. this means that we often get away with drawing just a single row of pixels. http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/libs/gtkmm2ext/fastmeter.cc see the vertical_expose() and horizontal_expose() methods. Note that we are also using precomputed pixbufs and just blitting them. Thanks for the advice. It's a very cool approach to use except I'm working with C. I'm not sure I'm up for porting from c++ to c right now. I am taking a slightly different approach to the visual aspect as I have added a glassy bubble overlay and the notches sit on top of the overlay. The meters are redrawing under the overlay to give the effect of being inside a glassy tube. So basically I have to redraw the whole thing each time unless I change the code to use the above method. The meters by themselves don't add any noticeable load. Do you think this memory leak can be fixed without having to completely redo the class to use precomputed bixbufs while porting from c++ to c? Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] GUI for audio application
2009/12/29 Arnold Krille arn...@arnoldarts.de: Very shiny. However, pretty useless as far as screen real-estate goes. 100 or so pixels either side for 'screws' is not necessary either. And pixel-based guis are _so_ last century. When you want good guis, that is usable and scalable and good looking, its not about doing in gui what you do in gimp, but doing in gui what you do in inkscape... I disagree. 1. rendering complex SVGs can be very time-consuming 2. scaled SVG can look worse than scaled px graphics (depends on design, renderer) 3. some graphic-effects cannot (yet) be achieved with vector graphics (think of all the gimp plugins..., photo realism) SVG has benefits for some areas, but it is not a replacement for pixel art. Two can have different opinions about a certain design, but should not be against design as a process of thinking about beauty, attraction and usability. Even the CML is a kind of design, if you want to see it as that... neither the worst, nor the best. In software, usability has priority over beauty (usually). IMO, the screws are totally acceptable here, as design elements, since they don't prevent usability nor introduce optical overload. Possible interpretation: The screws add imaginary value, by offering the user something known, real, by pretending materiality. If we only did the necessary, our world would look poor -- ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
On 12/31/2009 04:11 AM, James Warden wrote: Hello Patrick et al, I ported the ardour fast meters from C++ to C. Look into guitarix's code (GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it is very CPU friendly, the algorithm focusing only on the deltas from one event to the next. Hermann took care of the layout and that's what he was talking about when he mentioned something about the box_expose function. Ahhh, I was confused by the file name being GtkFastMeter.cpp so didn't look into it until now. My only concern before attempting to switch to this class is that maybe it won't solve the problem I am seeing. Do the notches get overdrawn by the meters? It looks like they are separately positioned so as to not have any conflict. I guess it shouldn't be a problem because the meters in ardour have notches and levels in the same coords but I don't really want to find out that it is after going to the trouble of inserting it to my codebase. I feel like I am basically finished with these meters if I could fix the memory leak. I'm wondering if it could be a gtk bug that is being picked up. Maybe it's just that I shouldn't be making so many calls to pango? :-/ Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] aseqmm 0.2.0 released
didn't mm originally mean minus minus, as a joke against C plus plus ? I could be wrong though. Seriously, who gives a shit ? This dude is also quite creative when it comes to picking names : http://www.linux-magazine.com/Online/News/Con-Kolivas-Introduces-New-BFS-Scheduler J. --- On Tue, 12/29/09, Patrick Shirkey pshir...@boosthardware.com wrote: From: Patrick Shirkey pshir...@boosthardware.com Subject: Re: [LAD] [ANN] aseqmm 0.2.0 released To: linux-audio-dev@lists.linuxaudio.org Date: Tuesday, December 29, 2009, 8:34 PM On 12/30/2009 05:52 AM, Pedro Lopez-Cabanillas wrote: On Tuesday, December 29, 2009, Patrick Shirkey wrote: On 12/30/2009 12:39 AM, Pedro Lopez-Cabanillas wrote: On Tuesday, December 29, 2009, Paul Davis wrote: i notice that SDLmm has not had a commit in nearly a year, and appears to have been named under a similar belief as your own. Is it about belief? There is something about that in the Universal Declaration of Human Rights. Article 18: Everyone has the right to freedom of thought, conscience and religion. I would also add the GUI toolkit and frameworks. Maybe you know the text of a Law, or a sacred text source of the absolute truth, where it is stated that a library name ending in mm must not be used by those not belonging to the congregation of true believers, under pain of heresy ? I think it is more about the numbers game. Basically there is a pattern that has been established by developers who have chosen to end their apps names with mm. Your app falls outside of the pattern so it may be confusing for people who come across it to learn that it is not adhering to the pattern. You are right, of course it is about numbers. There is a majority of people imposing their point of view over a single one, that is alone and looks easy to beat. I can understand the frustration of a confused victim that reads aseqmm and thinks it is something different of what it really is, then he reads the description that says This library is a C++ wrapper around the ALSA library sequencer interface, using Qt4 objects, idioms and style. This poor victim must be protected, even if that means stoning me preventively. Probably a more likely scenario is that a user who is knowledgable in such things will read the description and think Hmmm, that's a strange name for such a library, I wonder what other interesting design choices have been made. Btw, you are free to perceive this as constructive feedback or simply criticism. I have no intent on the latter though. Patrick Shirkey Boost Hardware Ltd So, I am thinking about changing the name of the library for Lapidation in the next release. It will be interesting to write a little chapter for the documentation, explaining the name's history and why it had to be changed. What do you think? An analogy could be a sushi restaurant called Bobs meat extravaganza. Technically they do serve some meat in the restaurant but it's probably going to be confusing for those who like to consume copious amounts of beef. I don't imagine a crowd of angry people complaining the restaurant's owner to force him to change the name. If you don't like the meal or the name, you should avoid dinning there. That's all. I feel part of the community of Linux Audio Developers. I know that there is a majority using certain toolkits and technologies, they are different to mine. I'm alone or among a little minority. And so what? Are we developers or sheep? Regards, Pedro ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
On 12/31/2009 06:30 AM, hermann wrote: Am Donnerstag, den 31.12.2009, 05:36 +1100 schrieb Patrick Shirkey: On 12/31/2009 04:11 AM, James Warden wrote: Hello Patrick et al, I ported the ardour fast meters from C++ to C. Look into guitarix's code (GtkFastMeter class). It is a direct translation from gtkmm2ext. I picked it up because it is very CPU friendly, the algorithm focusing only on the deltas from one event to the next. Hermann took care of the layout and that's what he was talking about when he mentioned something about the box_expose function. Ahhh, I was confused by the file name being GtkFastMeter.cpp so didn't look into it until now. My only concern before attempting to switch to this class is that maybe it won't solve the problem I am seeing. Do the notches get overdrawn by the meters? It looks like they are separately positioned so as to not have any conflict. I guess it shouldn't be a problem because the meters in ardour have notches and levels in the same coords but I don't really want to find out that it is after going to the trouble of inserting it to my codebase. I feel like I am basically finished with these meters if I could fix the memory leak. I'm wondering if it could be a gtk bug that is being picked up. Maybe it's just that I shouldn't be making so many calls to pango? :-/ Maybe you try it with cairo, instead pango, :-) That's a good idea. Do you have an example of how to use it. it's 6:50am here and I'm a bit past thinking now :-) Anyway I have decided to go ahead without the text values for now. I've run out of time and may not get any more for a couple of weeks. I would rather release what I have now for people to play with than hold onto it for any longer. Thanks for your help though. It was very useful and interesting to get more details on the meters that are available for gtk. Cheers. Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JackEQ-0.5.8: smooth and shiny
Hi, I am pleased to announce a long overdue release of jackEQ v0.5.8 code name: Smooth and Shiny You can find the tarball at the new home: http://djcj.org/jackeq It's been almost 4 years since a release and this one comes with many useful new features including... - Save/Restore UI state (with autosave on exit/quit). - Shiny new meters merging gtkmeter and gtkmeterscale into one class. - Mute buttons on all channels, right click to enable/disable. - One click eq reset (well two actually for your safety) - A revised UI theme taking advantage of Cairo rendering engine in gtk. Mmmm gradients. Please let me know if you encounter any problems. Otherwise, enjoy and Happy New Year for 2010!!! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JackEQ-0.5.8: smooth and shiny
Patrick, You kept edit backups of certain source files in the tarball (those ending with ~ created by emacs or other text editor you are using). J. --- On Wed, 12/30/09, Patrick Shirkey pshir...@boosthardware.com wrote: From: Patrick Shirkey pshir...@boosthardware.com Subject: [LAD] JackEQ-0.5.8: smooth and shiny To: LAU linux-audio-u...@lists.linuxaudio.org, Linux Audio Developers linux-audio-dev@lists.linuxaudio.org, linux-audio-annou...@lists.linuxaudio.org Date: Wednesday, December 30, 2009, 3:00 PM Hi, I am pleased to announce a long overdue release of jackEQ v0.5.8 code name: Smooth and Shiny You can find the tarball at the new home: http://djcj.org/jackeq It's been almost 4 years since a release and this one comes with many useful new features including... - Save/Restore UI state (with autosave on exit/quit). - Shiny new meters merging gtkmeter and gtkmeterscale into one class. - Mute buttons on all channels, right click to enable/disable. - One click eq reset (well two actually for your safety) - A revised UI theme taking advantage of Cairo rendering engine in gtk. Mmmm gradients. Please let me know if you encounter any problems. Otherwise, enjoy and Happy New Year for 2010!!! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Is TerminatorX development stalled?
Hey guys, thanx for the quick replies. I've already started looking at the code of tX. Its a very clean codebase, I was able to fix a bug (saving/restoring the midi event assigned to the trigger of a turntable) in 10 min. I will look at the programs. I would like to know how many of you need the feature of being able to adjust the tempo of a turntable in an ableton live fashion. Gerald On Tue, 2009-12-29 at 19:21 +0100, gerald mwangi wrote: Hello Guys, i'm new to this mailing list. I just wanted to know if TerminatorX development is stalled. The last version is 3.82 since 2 years or so. Or is there another Program of the sort and under development. Please let me know, maybe i'll pick up development of TerminatorX. Gerald ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JackEQ-0.5.8: smooth and shiny
Excerpts from Patrick Shirkey's message of Wed Dec 30 21:00:15 +0100 2009: Hi, I am pleased to announce a long overdue release of jackEQ v0.5.8 code name: Smooth and Shiny You can find the tarball at the new home: http://djcj.org/jackeq It's been almost 4 years since a release and this one comes with many useful new features including... - Save/Restore UI state (with autosave on exit/quit). - Shiny new meters merging gtkmeter and gtkmeterscale into one class. - Mute buttons on all channels, right click to enable/disable. - One click eq reset (well two actually for your safety) - A revised UI theme taking advantage of Cairo rendering engine in gtk. Mmmm gradients. Please let me know if you encounter any problems. Otherwise, enjoy and Happy New Year for 2010!!! As it happens I had a look at it just a few minutes ago, saw the last release date and forgot about it. Now I made it available for Arch Linux. It builds and starts. There are a couple of warnings at buildtime, tell me if you want to know about them. Regards, Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Is TerminatorX development stalled?
OK, I'll start to work on it, but it will take some time. Maybe someone has experience with librubberband? Gerald On Thu, 2009-12-31 at 07:33 +1100, Patrick Shirkey wrote: On 12/31/2009 07:22 AM, gerald mwangi wrote: Hey guys, thanx for the quick replies. I've already started looking at the code of tX. Its a very clean codebase, I was able to fix a bug (saving/restoring the midi event assigned to the trigger of a turntable) in 10 min. I will look at the programs. I would like to know how many of you need the feature of being able to adjust the tempo of a turntable in an ableton live fashion. Gerald If you can do it then you will make many people very happy :-) Cheers. Patrick Shirkey Boost Hardware Ltd On Tue, 2009-12-29 at 19:21 +0100, gerald mwangi wrote: Hello Guys, i'm new to this mailing list. I just wanted to know if TerminatorX development is stalled. The last version is 3.82 since 2 years or so. Or is there another Program of the sort and under development. Please let me know, maybe i'll pick up development of TerminatorX. Gerald ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Is TerminatorX development stalled?
gerald mwangi wrote: OK, I'll start to work on it, but it will take some time. Maybe someone has experience with librubberband? Gerald Is it really a good idea to spend time on TerminatorX? Couldn't you better add 'Abbleton features' to mixxx, hydrogen or non-sequencer/daw? It looks to me those apps have more potential to survive. I could be wrong though. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Is TerminatorX development stalled?
On Thu, Dec 31, 2009 at 6:53 AM, rosea grammostola rosea.grammost...@gmail.com wrote: Is it really a good idea to spend time on TerminatorX? Couldn't you better add 'Abbleton features' to mixxx, hydrogen or non-sequencer/daw? It looks to me those apps have more potential to survive. I could be wrong though. Regards, \r While I agree with the sentiment here, I'd like to add a voice of support for continued development on TerminatorX. To me it has always been one of the most fun apps on linux to play with, and I think that's vital. The one thing that always held it back to me was individual track outputs in Jack - mixing down to stereo was always a buzz killer to an otherwise fast and enjoyable workflow. -m ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] memory leak assistance
On Wed, Dec 30, 2009 at 1:39 PM, Patrick Shirkey pshir...@boosthardware.com wrote: Do you think this memory leak can be fixed without having to completely redo the class to use precomputed bixbufs while porting from c++ to c? Have you tried running under valgrind? a 200meg leak should be simple to spot with it. http://live.gnome.org/Valgrind iain ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
