On Mon, Sep 26, 2011 at 05:38:24PM +0000, Fons Adriaensen wrote:
> > Those of you who own a Multiface, Digiface or RPM: Could you give
> Does not compile. The installed header doesn't define
> anything RPM, and you don't supply a new one.
Good point. Now? http://adi.loris.tv/hdsp-test-20110927.tgz
Hello.
I noticed mudita24 SVN was in a sad state, crashing the whole system.
There were already significant changes and improvements since release 1.0.3
So I fixed 'er up. Please give it a spin so we can put out a release sometime.
mudita24 is the updated replacement of envy24control, the gui for
ice1712-based audio hardware.
http://code.google.com/p/mudita24/
subversion: svn checkout http://mudita24.googlecode.com/svn/trunk/mudita24
mudita24-svn
1) Moved to cmake build system. No more autotools :)
(The default install location is /usr/local. It can be changed -
try the handy 'ccmake' gui).
2) Fixed wrong alsactl location. Now cmake looks for alsactl.
Override with environment variable ALSACTL_PROG.
3) Added usage info.
4) Fixed serious fatal X error: height too big. Was far too many markings,
brought down the system, due to lowest alsa db value now returning
-9999999. Installed some limits.
5) Executable is now called mudita24 instead of envy24control.
This should help kind packagers out there finally get this into the repos.
Cheers. Tim.
hi,
i am interested which jack supporting audio applications currently also support jack-session.
http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session holds a list, but i think it is a bit out dated.
imo, it would be nice, if involved linix audio devs would add her jack-session application to this email.
a really easy way to collect a list of this apps. i am involved in hydrogen so this is why i add only this application to this list.
greetings and thx in davanced,
wolke
list of jack-session supporting applications:
* hydrogen0.9.6 (svn head)
On 23 February 2011 22:11, David Robillard <d(a)drobilla.net> wrote:
> SLV2 is now based on two new libraries: Serd (RDF syntax) and Sord (RDF
> store). Both are roughly 2 thousand lines of C, solid and thoroughly
> tested (about 95% code coverage, like SLV2 itself). Serd has zero
> dependencies, Sord depends only on Glib (for the time being, possibly
> not in the future).
Can you point me at the API or code? I couldn't see it in a quick
browse on your SVN server.
I have a library (Dataquay,
http://code.breakfastquay.com/projects/dataquay -- preparing a 1.0
release of it at the moment, so if anyone wants to try it, go for the
repository rather than the old releases) which provides a Qt4 wrapper
for librdf and an object-RDF mapper.
It's intended for applications whose developers like the idea of RDF
as an abstract data model and Turtle as a syntax, but are not
particularly interested in being scalable datastores or engaging in
the linked data world.
For my purposes, Dataquay using librdf is fine -- I can configure it
so that bloat is not an issue (and hey! I'm using Qt already) and some
optional extras are welcome. But I can see the appeal of a more
limited, lightweight, or at least less configuration-dependent
back-end.
I've considered doing LV2 as a simple example case for Dataquay, but
the thought of engaging in more flamewars about LV2 and GUIs is really
what has put me off so far. In other words, I like the cut of your
jib here.
Chris
JACK 0.121.3 is a bug fix release containing (almost) no new
functionality. It is required if you want to use JACK1 on OS X with
any clients that use weak linkage for JACK feature detection (e.g.
Ardour). Changes:
* Make the printed output of jack_iodelay more useful to actual users
* Compilation fixes for OS X (particularly PPC architectures)
* Remove SSE-related messages during startup
* Fix a few argument type declarations for a few functions
* OSS backend: fix a call to yet undefined engine instance
http://jackaudio.org/downloads/jack-audio-connection-kit-0.121.3.tar.gz
Hi all,
There is currently some network problem affecting the vt.edu uplink
which hosts linuxaudio.org. We do not yet know the details and the issue
is outside of our scope but the Virginia Tech Admins are on to it.
Apparently low bandwidth requests - such as email - still make it
through occasionally. We're sorry for the inconvenience.
greetings,
root(a)linuxaudio.org
Hi everyone,
I'm porting the AMS internal modules to LV2 plugins to be used in Ingen.
Small problem is, AMS uses VC (even the output of the VCOs that
produce sound) when Ingen uses PCM...
So far, my research seems to lead that a simple multiplication by 16
of the VC output should convert it to PCM, and vice-versa.
That doesn't seem right though, as I would think the sample rate
should be involved in this conversion!
Would somebody have any ideas?
Thanks in advance guys,
Aurélien
Hi!
Back in July, I've hacked a bit on the hdsp driver to fix the RPM
support.
Those of you who own a Multiface, Digiface or RPM: Could you give
http://adi.loris.tv/hdsp-test-20110925.tgz
a whirl?
I just want to make sure the RPM fixes don't introduce any regression,
so if your Multiface/Digiface was working fine before, I hope nothing
changes.
If you own an RPM, the box should be detected automatically now.
I've verified it with my Cardbus based Multiface so far, but I'd love to
have a broader test phase before sending the patches upstream.
TIA
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
On 25 September 2011 01:54, Tim E. Real <termtech(a)rogers.com> wrote:
> On September 24, 2011 06:51:33 pm you wrote:
>> The Aurora GTK theme makes the interface look messy due to labels
>> sitting half in and half out of the shaded frames. More a design
>> fault/oversight with the Aurora theme though.
> You mean the "H/W In 1" etc sitting in half grey/light grey area in the
Yes.
> snapshot? Observed here with only with Aurora, the other ten installed
> themes, including clearlooks, were fine - the two greys were equal.
> But oddly, in the GTK theme changer, the frame labelled "Preview"
> looked OK for Aurora.
I'm using XFCE so didn't see a preview.
> Aha.. That means it's because of our Tabbed Notebook. Yes, I can see
> it in your snapshot and here. The surrounding grey is the same as
> the tab grey.
So something wrong with how you're doing the tabs?
> Industrial looked pretty ghastly with it's slider troughs filled with blue.
> Suppose they all have their uses...
>
>>
>> With certain GTK themes, the slider highlights are unexpectedly
>> inverted so that they go from the top (+0db) down to the slider.
> Oh, you mean say, the industrial blue-filled slider troughs?
> Yep. I know. The reason IIRC is the sliders are all constructed upside-down!
Ok. I did begin looking at how they're drawn but then I got side tracked...
>> ...and being curious I tried compiling with -DGTK_DISABLE_DEPRECATED,
>> -DGDK_DISABLE_DEPRECATED, and -DGSEAL_ENABLE. You see I've been
>> brainwashed into removing deprecated code somewhere along the line and
>> have done quite a lot of it over the past couple of years. I've spent
>> the last hour or so, but decided perhaps would see if someone is
>> already doing it or not, or even if the dev's care about this kind of
>> stuff and want me to finish the job or not.
> Oh, I had no idea. So this is a good idea? IE reduces bloat? Or...
> One of my goals was to make sure gtk 2.4 was still supported - just in case
> some die-hards with older distros need it, because I needed some 2.6 stuff,
> so I didn't want to disappoint anybody. More complicated though.
> So you'll see macros (I think) HAVE_GTK24 and HAVE_GTK26
> Will you still support 2.4? No big deal to me if we have to move up.
>
>>
>> See attached patch for what I've done so far. The gtk_pixmap related
>> calls are the most trouble and open up a whole can of worms known as
>> cairo so I haven't not touched that.
> Will try patch...
>
> Yeah, themes eh?... Here in MusE Qt land, I'm struggling with wacky 'rogue'
No, not themes this time. Deprecated GTK/GDK API. If you look in GTK
docs, gtk_pixmap_*() functions are "deprecated and should not be used
in newly written code". But if you want to support GTK 2.4 still then
this might not be a good idea.
-DGSEAL_ENABLE prevents access to gtk structure members, the reason in
the patch you'll see stuff like:
- gdouble min = adj->lower;
+ gdouble min = gtk_adjustment_get_lower(adj);
with gtk_adjustment_get_lower() being available since 2.14. DevHelp is
pretty useful for this kind of stuff, but not all replacements for
deprecated calls mention since which gtk version they've existed.
gtk_widget_get_allocation() since 2.18 (this again due to -DGSEAL_ENABLE).
The deprecated gdk_draw_rectangle are actually the most trouble as the
GTK gurus want you to replace all that code with code that uses Cairo
which does things quite differently == a PITA.
When I say "...I've been brainwashed into removing deprecated code..."
I mean that I'm doing it faithfully without really knowing the
consequences. Faithfully believing I'm preparing for the future but
really it's only forcing people to upgrade.
-DGSEAL_ENABLE is used if you want to prepare your code for when GTK3
is the standard version and GTK2 is removed from distros. I think GTK1
has really only very recently been removed from standard distros
repos?
I guess you have to weigh all this stuff up. Preparing for when only
GTK3 exists isn't an urgent scenario for example.
James.
