Re: [linux-audio-dev] Re: Free Software vs. Open Source: Where do*you* stand?

[Pete Bessman]

On Tue, 2006-02-21 at 01:31 -0800, Kjetil S. Matheussen wrote:
> And here is the sound:
> http://ccrma.stanford.edu/~kjetil/jack_capture_1.ogg
> 
> I'd say its pretty good to be done by an amatour in a hurry. :-)

Well, that was interesting.  I had no idea this program even existed,
but you may be on to something with it.  I'll keep a lazy eye on it ;-)

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?

[Pete Bessman]

On Tue, 2006-02-21 at 16:30 +0100, David Kastrup wrote:
> Chris Cannam <[EMAIL PROTECTED]> writes:
> 
> > An irony of both open source and free software is that they make it
> > easy to forget that all software is almost always written by decent
> > humans -- for example, by implying that proprietary software
> > developers are less moral and so less significant.  If my free
> > software work puts a company or its developers out of work, then
> > that's a problem for my conscience.  It's not a victory for free
> > software.  And it's not "just business", because it's not business.
> > I will have damaged people's livelihoods, for fun.
> 
> That particular argument does not hold water at all, sorry.  Following
> your kind of logic, people caring for peace on Earth are damaging the
> livelihoods of weapon producers, decent people mostly, and that merely
> for their selfish desire of a world worth living in.

No, this is a bunch of BS.  You're equating software producers with
weapon producers, who you're equating with evil (and, implicitly, weapon
users, a fact which I find personally insulting).  That's all wrong, but
the salient point is that Chris stipulated that proprietary software
producers *aren't* evil!  The only way they can be evil is if you
stipulate a moral code which dictates as much.

They're not torturing babies, for chrissakes.

> If their livelihoods get tougher because of a world where work is
> shared and exchanged between consenting and cooperating humans, so
> much the better.  It is a byproduct one can live with.

Yeah, ever heard of capitalism?  Or do you have a bone to pick with
that, too?

Seriously, there are better things to do than demonize proprietary
software producers.  Go kill a terrorist if you need somebody to beat up
on, at least you'll be making the world a better place in the process.
Last I checked, Microsoft wasn't bombing any subways.

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

Re: [linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?

[Pete Bessman]

Chris, pay no attention to Dave.  That message was bloody brilliant!
Very enlightening, head slapping "Oh man!  That's IT!" read.  You should
really consider expanding that and putting it up somewhere in essay
form, they're are a quintillion people who could benefit by reading it.

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

Re: [linux-audio-dev] Re: [linux-audio-user] Free Software vs. Open Source: Where do*you* stand?

[Pete Bessman]

On Tue, 2006-02-21 at 11:06 +0100, David Kastrup wrote:

> Pete complains that maybe he has listened too much to Stallman.  I am
> afraid if he did, he did not understand too much.  Stallman is not a
> person who promises superior quality of free software: that would be
> the panacea of the "Open Software" camp.  Stallman says that he
> refuses to use non-free software for ethical reasons.

I know what he stands for, I just don't agree with it anymore.  I think
it's illogical, and I think my subconcious always rejected it, and as a
response to this psychological discomfort, I think I developed a knee-
jerk "sucks" response to proprietary software.

It's what psychologists call projection.  When confronted with a
shortcoming in yourself, you project that same shortcoming onto others
so you don't feel like it's totally yours to deal with.  You think OSS
has UI issues?  You should see windows!  You think dependency hell
sucks?  Well go check out DLL hell!  Etc.

Basically, after years of forcing myself to accept a dogma that, upon
closer inspection, I think is a bunch of baloney, I have a lot of poison
in my brain that I need to remove so that I can think clearly, calmly,
and rationally.  There are some ex-communists in the libertarian circles
in which I tread, and they have the same kind of problem WRT Marx and
communist ideology.  And current communists are engaging in projection
and the like on an awe-inspiring scale.

BTW, this isn't meant to equate OSS with communism.  I just want to
drive home the point that I did not misinterpret one iota of the
Stallman verse --- I'm just tossing it in the trash bin along with my
Torah.

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

Re: [linux-audio-dev] Re: [linux-audio-user] Free Software vs. Open Source: Where do*you* stand?

[Pete Bessman]

On Tue, 2006-02-21 at 12:05 +0100, Thorsten Wilms wrote:
> On Mon, Feb 20, 2006 at 11:15:48PM -0500, a Zombie wrote:
>  *too much*

I know...

> Somewhen around the Milennium, when I had no internet access and  
> didn't know shit about Linux and co, I bought Cubase VST.
> Was a great tool, except when it crashed and took Windows with 
> it. I hate to spend money on crashing software.
> I would have had to buy an update to make it run on a newer 
> than 98 Windows. Win 98 doesn't like PCI Express. This lockin/
> update stuff is one very big reason for me to stay away from 
> propietary software.
> Another one is copy-protection and how it gets in the way of 
> hounest customers only, as the crackers laugh.

This is actually about what happened to me when I first made the switch.
Things have definitely gotten more stable in Windows land, and OSX is
relatively solid, but Linux is still teh weener here.  And, obviously,
vendor lock-in and zealous copy-protection aren't an issue.

> I like the idea of being able to revisit projects after several 
> years. Open Source makes this far more likely to work.
> I hate the idea to put hours and hours of work into closed 
> file formats. It's like putting my work into black boxes that 
> are someone else's property. How nice of them to grant me acces 
> to my own work! With DRM and stuff this can only become worse.

This is a very important point, and I think it underscores the fact that
costs and benefits are variegated things.

> Finaly, I make music for the fun of it, not for being the best.
> In this age of diversity and plentifulness, creativity is much 
> about being just that bit different, I think (being all 
> different means burning bridges).

I wouldn't say I necessarily aim to be the best musician, since that
seems to be something which can't really be objectively determined.  But
I do like the cutting edge, and the fact that I can't make the kind of
music I want to make with the tools at my disposal is maddening.

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

Re: [linux-audio-dev] Re: [linux-audio-user] Free Software vs. Open Source: Where do*you* stand?

[Pete Bessman]

On Mon, 20 Feb 2006 15:21:19 -0500, "Paul Davis"
<[EMAIL PROTECTED]> said:
> On Mon, 2006-02-20 at 14:55 -0500, Pete Bessman wrote:
> > So let's hear it!
> >
> > WHAT is your NAME?
> >
> > WHAT is your QUEST?
>
> i can hack ardour part time while i work. i can hack ardour full
> time while i live the rest of my life. but i know for sure that
> i definitely can't get into philosophical debates with the
> recently deceased while i work full time on ardour and live the
> rest of my life.

Fool --- I'll eat your brains!

All seriousness aside, I'd like to address the myriad responses
I've received.

First, I want to reiterate that I don't want to get into a war about
morals.  Moral philosophy is an old enterprise, and it's rate of
progress in recent centuries has not been great (to quote Friedman).
I'm a libertarian, I believe in the right to contract, so I believe
in the right of a software producer to require a user to agree to an
EULA or walk.  I don't think this is really at all in conflict with
my belief that our current copyright law is a little whack --- I
think our contract law is just fine, and that's where I see the meat
of the validity and enforceability of proprietary software licenses
as coming from.

Now, naturally, you might disagree --- and obviously, plenty of
people here do. That's not the discussion I wanted to have, though!
Something of that depth is better served by a blog post than a flamewar
here, I think.

That said, I hate to say it, but I think I'm going to go ahead and stir
up some more controversy.  I agree that, in many instances, linux audio
probably meets and exceeds the "good enough" test --- that is, it either
gets the job done flawlessly, or can be made to done so with a little
work.  Straight recording, mixing, and mastering are probably at this
level, and I'd wager you can produce pro-quality stuff with relative
ease using current tools in this realm.

However, as far as synthesis, sampling, sequencing, and other assorted
electronica, I don't think it really cuts the mustard --- at least for
the cutting edge.  Sure, it can do scene music and minimalism and
abstract-avant-
garde stuff.  But take a listen to the latest from, say, Delerium, or
Front Line Assembly --- how in the world are you going to pull that off
with Hydrogen, ZynAdd, Seq24, rosegarden, muse, jack-rack, and
LinuxSampler?

Guitars and drums haven't changed in a while, nor has recording.  But
cutting-edge electronic music is defined by running on cutting-edge
electronic technology.  Go browse through musiciansfriend.com and take a
look at all the various proprietary offerings in this department.  Heck,
just look at Project5 or FL studio and the plugins it comes with.  You
simply have more tools at your fingertips in the proprietary world.  And
further, I agree with Russ --- the sequencing side of things just isn't
really there.  Maybe for stuff that's supposed to sound realistic.  But
try programming a complex synth line, replete with legatos and
extremely-
small interval fragments, and add in automation of filfreq, reso,
panning, etc.  It's doable, but it's painful.  And the more time you
spend fighting an app, the less time you spend making music.  There's a
reason tb303 synth apps are so popular, and it *ain't* just because the
tb303 hardware is rare --- it's because the truth is, it's a feckin'
PITA to use.

For the kind of stuff I'm interested in (see my above band references to
get an idea), I think it is eminently clear that Linux isn't good
enough.  Maybe it is just me, but I have been struggling intensely for
some time to get things to work out, and it just ain't happening.  If
anybody here has got some tracks that can prove me wrong, I'd love to
hear 'em.  And maybe I'll get back to Windows world and have the same
problems --- but I sincerely doubt it.

I'm not sure what it is --- some times, open source whomps up,
sometimes, it just can't keep up.  For the realm of music I'm in, it
lags.  Same thing for videogames (obviously). Maybe this will change
with time, but with all the new stuff that's been going on, the gap has
been widening if it's moved at all.  This causes a lot of cognitive
dissonance for myself, and I'm not sure why.  Maybe I drank too much GNU
kool-aid as a kid, or maybe it's all the years I've logged in emacs.
Most likely, I'm just obsessive compulsive, and I like to be able to say
"this is this and that is that." The fact that I can't yet figure out
the rule for when open source is going to produce the better product is
probably driving me slightly mad.  That, and the fact that years of
believing in Stallman gospel have probably deranged me a bit.

Man, I'm not sure where I'm going with this

[linux-audio-dev] Free Software vs. Open Source: Where do *you* stand?

[Pete Bessman]

Well, I'm about to crack open a can of worms, but let me just say that
I'm 100% not interested in starting any debates/fights/riots/states-of-
emergency.  All I'm interested in is hearing where people stand and why
--- I don't want to persuade people one way or the other, and I'd like
to ask that everyone restrain themselves when feeling the urge to tell
someone that they're wrong.

I'm doing this because, after having been a part of this community for a
while, and a developer for some time, I'm having an "is it all worth
it?" moment.  I personally like the Linux environment more than Windows
and Mac --- I find it to be better suited to a technically inclined
person like myself.  And with each iteration of the distros and desktop
suites, it comes closer to meeting and surpassing the competition in
core computer functions.  It's already got the server side of things
dominated, and when it comes to surfing the web, checking your email,
burning cds, listening to music et al, it's definitely a contender.
Better in some areas, worse in others, and mostly only suffering because
of proprietary technologies that have become standard.

But, and this what it's all about, when it comes to my personal reason
for living --- music --- I'm forced to admit that on technical merits
alone, I have a hard time arguing for Linux.  I'm personally a "just for
fun" kind of guy.  I'm basically from the utilitarian-libertarian
school, and while I did try the "free as in freedom" thing for a while,
it was a poor fit.

I happen to have some very significant qualms with the way "intellectual
property" (if RMS was right about anything, it's that this is a poor
term for non-rivalrous creative goods) is currently being handled ---
there is a huge and easily observable disparity between what the laws
say and what people do, and common sense tells you that that probably
means the laws are messed up.  So, for me, open source and creative
commons are a way to sort of skirt the issue, or at least push things in
a better direction.  Also, there's something just sexy about open
source.  But for me, that's where the non-technical merits of it stop.

What I'm saying is, I think we can all agree that, when an open source
solution is technically superior to, or on par with, a proprietary
solution, then the open source solution is the way to go.  But what
about when the proprietary solution is better?  If the open source
solution is good enough, then it makes sense to use it since it's bound
to be cheaper.  But if you really need the best tool for the job, then I
don't see the justification for using the open source solution.

Things obviously change when you're a developer, since you can bring the
open source solution up to, or beyond, the level of the proprietary
solution.  The question, then, is will you get more pleasure out of
doing so than pain?  That's where I am right now.  I really, really want
to get an album out --- and I also want it to be really, really good.  I
want to use the best tools for the job, and in my evaluation, those are
proprietary tools.

OTOH, with a little work, I think the LMMS + Ardour can actually be the
best, or at least good enough.  I also happen to enjoy doing open source
development, so this wouldn't be a bad path to pursue.  But ultimately,
I want to get back to making the best music that I can make --- it's for
that reason that I think I'm going to finally go back to a dual boot
machine for the first time in 6 years, and take a vacation in Windows
land.

None of this is to say that I'm through with Linux and open source as
music making solutions --- far from it.  And I'm certainly *not* trying
to encourage any body to follow my lead.  In fact, I hope people get
pissed reading this and double their development efforts :-)  It's just
that, right now, rolling proprietary sounds more appealing than rolling
open.

This email is way, way longer than I intended it to be, and for that I
apologize.  Remember that I'm not looking to stir up any hostilities, I
just want to hear where people stand on The Issues and get a sense of
the community.  I predict that there are people here on a moral mission,
and there are people here because they get a chubby out of openness and
collaborative development and such.  But I don't think I'm going to see
anybody who's primary interest is making music --- although I'd love to
be proved wrong, and I certainly think that things will be different in
the future as the tools get better.

So let's hear it!

WHAT is your NAME?

WHAT is your QUEST?

WHAT is your FAVORITE ALBUM?

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

[linux-audio-dev] [ANN] No More Specimen

[Pete Bessman]

Ladies and Gents,

I can hack specimen while working full time.  And, I can hack specimen
while studying full time.  But, and this is empirically verifiable, I
can't hack specimen while both working and studying full time.  And my
situation is not likely to change for another year or so.

What this means is that I'm just not cut out to run a project right now,
unless I want to put it into maintenance mode.  Really, that's where
specimen has been for the past six months anyway, and I've been doing a
rather piss poor job at that modest role!  My efforts are better applied
to tasks where smaller chunks of time can go a greater distance.

I don't have any regrets --- this was my first real programming project,
and I learned a lot.  But the truth is that LMMS is more specimen than
specimen right now, and it has an active development and user community
surrounding it.  Plus, I've always been a musician and an artist first,
and a programmer second.

All told, it's time to throw in the towel on this one.  In a way, this
is a bummer --- I've put a lot of sweat and tears (literally) into this
project over the past couple of years, and it has come an incredible
distance.  But I'd be a fool to think that I'm better off keeping it
afloat than making music and contributing to other projects.

And truthfully, it's a huge relief to get this announcement out.  A
sense of obligation is what kept me from making it sooner, but in
retrospect, that's pretty ridiculous.  Considering that I'm an "open
source, just for fun" guy, and not a "free software, as in freedom"
type, it doesn't make a lot of sense to keep going when pain exceeds
pleasure.

This isn't the end of my open source music development, however.  I hope
to help take LMMS to the next level, and contribute to other projects
that will help make Linux a competitor in the music industry.  Things
like ardour2, lash, jack-midi, vst, dssi, ladspa et al are the keys to
our future in this regard.  And I look forward to getting back to
hardcore hacking in a few years, when I've got my life settled down and
I'm not putting in 80 hours of work and school a week.

Take care everybody, and may the funk be with you.

-- 
Pete Bessman
http://gazuga.net
"So this baby seal walks into a club."

Re: [linux-audio-dev] [OT] 2-D slider widget?

[Pete Bessman]

On Thu, 2005-07-28 at 17:01 +0100, James McDermott wrote:
> Pete,
> 
> You might like to look at a demo program I made as part of my GTK+
> education - it's a functional xy-controller:
> 
> http://www.skynet.ie/~jmmcd/software/xy-controller.tar.gz
> 
> But I actually made the xy-controller directly from the drawingArea
> widget. Ie, I didn't make a new reusable widget (maybe it'll inspire
> you to do that for PHAT), because that seems like a lot more work!
> Maybe when I learn a bit more...

I appreciate the code, James.  Is this stuff GPL'd or some-such?

Peace,

-Pete

Re: [linux-audio-dev] [a bit OT] scroll and zoom conventions

[Pete Bessman]

On Wed, 2005-07-27 at 20:00 +0200, Richard Spindler wrote:
> I've started to use a "Scalebar" in my last project (
> http://www.matthiasm.com/flScale.html )
> And a believe it's an interface element that's quite useful, it works
> like a scrollbar, but has little buttons attached at the ends of the
> sash that manipulate the zoom level by dragging and streching the
> sash.

That's pretty interesting.  I'd be interested to hear what Thorsten
thinks about it --- he's always on the lookout for the latest and
greatest in GUI stuff.

Peace,

-Pete

Re: [linux-audio-dev] [OT] 2-D slider widget?

[Pete Bessman]

On Tue, 2005-07-26 at 17:00 +0100, James McDermott wrote:
> Has anyone written code for, or even just seen, a 2-D slider widget?
> What toolkit was it in? Do people around here prefer QT to GTK+, or
> vice versa, and does anyone use FLTK, or something else?

Oh yeah... x-y controllers.  Nice.  I'll have to add one of these to
PHAT.

Peace out,

-Pete

[linux-audio-dev] [ANN] Specimen v0.5.0 and PHAT v0.3.0

[Pete Bessman]

Ladies, gents, and those in between,

I got back into the hacking thing a couple days ago, and I'm pleased to
announce new versions of both the Specimen sampler and the Phat Audio
Toolkit.  As always, the real tip can be had at www.gazuga.net.  The
stuff that I remember changing follows:

Specimen

* Fixed CPU hogging
* Added keyboard for setting MIDI parameters
* Made patch list auto sorting
* Made volume logarithmic

PHAT

* Added a new widget, the PhatKeyboard

Stay tuned for more!

Peace out,

-Pete

[linux-audio-dev] A Taste of Things to Come

[Pete Bessman]

Hello Lists,

As some of you may know, I'm the guy who wrote Specimen.  And as a tiny
fraction of that some may know (or care), Specimen hasn't seen an update
in an exceedingly long time.

What, exactly, is going on?

The answer, dear friends, is simple: music.  My introduction to the art
of electronic music composition began precisely when Specimen
development halted.  For a few months, I fumbled around with countless
little songs in an attempt to figure out how one goes about the process
of coaxing the electrons in such a fashion as to result in sonic
euphoria.  And once I reached that point where the magnitude of my
suckiness became bearable, I began writing songs.

This process began in February with the assistance of an old friend, who
lent his discerning ear and exceptional bass talent to the effort.  And
yesterday, we finished step one --- general composition.  We now have 11
rough drafts that will be polished into a full length album and released
next fall --- 100% Linux and OSS produced.

It occurred to us that we might share some of this with all you folks
out there in Internet land, both to stoke the flames of anticipation and
to remind my adoring public that I have not yet shed this mortal coil.
So, I am pleased to present a collection of snippets from the
aforementioned tracks above, pieced together in an easy to swallow
medley:

http://www.gazuga.net/preliminary_beats.ogg
http://www.gazuga.net/preliminary_beats.mp3

And for those interested in staying abreast of the latest and greatest,
be sure to tune into The State of the Beat:

http://www.gazuga.net/blog

That's all for now, but don't worry --- I'll be back before you know it.
Kinda like herpes, only better.

Peace out,

-Pete

Re: [linux-audio-dev] [EMPLOYMENT] contractor sought for linux sample playback engine

[Pete Bessman]

On Wed, 2005-05-11 at 00:04 +0200, Fons Adriaensen wrote:
> but I've no desire to live in the US
> until at least the next regime change.

Hmm... in that case, I'll vote Republican again the next election.

Peace out,

-Pete

[linux-audio-dev] [ANN] Specimen v0.4.4

[Pete Bessman]

Normally, I don't announce minor releases, but this is an exception. 
The latest Specimen has a completely redone GUI, which I hope will make
using it suck a whole lot less.

Downloads: www.gazuga.net/downloads.php

Screenshots: www.gazuga.net/screenshots.php

This version of Specimen also relies on PHAT, so be sure you have the
latest version (0.2.2).

PHAT: www.gazuga.net/phat.php

This is a relatively ambitious endeavor, so please inundate me with bug
reports.  And yes, MIDI control is coming really, really soon. 
Seriously.

--Pete

Re: [linux-audio-dev] pkaudio/pksampler release

[Pete Bessman]

On Mon, 2004-09-20 at 08:56, Patrick Stinson wrote:
> PKSampler is a DJ sampler intended for a touch screen. It uses python and qt 
> to animate real 3D widgets created with PoVRay. Check out the screen shots! 

/me blinks

Whoa!  Eye candy!  In a linux app!

> There's lots of directions for this app to take, and I'd like to know if 
> anyone can get pksampler running on their machines. Works best with more than 
> one soundcard! Thanks!

Does it play well with jack?  I didn't see mention of this on the
linked-to webpages.  OH, nope, wait, there it is!  Cool, I'll have to
check this out, although I'm not exactly the DJ type.

--Pete

Re: [linux-audio-dev] OSC vs MIDI

[Pete Bessman]

At Wed, 1 Sep 2004 20:15:54 +1000,
Erik de Castro Lopo wrote:
> 
> On Tue, 31 Aug 2004 13:15:24 -0400
> Pete Bessman <[EMAIL PROTECTED]> wrote:
> 
> > The D programming language looks very promising in this regard, but
> > its newsgroup faces a daily battle with people who seem more
> > interested in creating a religion than a tool. 
> 
> I had a bit of a look at D and I was majorly underwhelmed. This
> is a direct descendant of C, C++ and Java. It extends this lineage
> a little, but completely ignores ideas from languages such as Perl,
> Python, Ruby and the whole constellation of functional languges.

That's actually precisely what I like about it.  D is, depending on
your vantage point, a modernized C, a cleaned up C++, or a
non-retarded Java (sorry, I can't think of a more diplomatic way to
say that).  That's all it's supposed to be.  There isn't exactly
a dearth of more experimental languages out there, I like seeing
a real grizzled and pragmatic language like D pop up.

--Pete

<http://www.gazuga.net>

"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] OSC vs MIDI

[Pete Bessman]

At Wed, 1 Sep 2004 09:49:36 +0100,
Steve Harris wrote:
> 
> Obejctive C is OK, it uses messages (smalltalk style) rather than method
> calls, and they have some performance limitations, but the class stuff is
> all sane.

Good call, I forgot about it at the time of writing.  It is quite
nice, and I like how the 'id' type obviates most of the need for
templates.  The only complaint I have is that I think the class
declaration/definition syntax is... goofy...  But that's certainly
tolerable.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] OSC vs MIDI

[Pete Bessman]

At Tue, 31 Aug 2004 16:02:43 +0100,
Steve Harris wrote:
> 
> I like the OO-in-C style of programming, its pretty much the best of both
> worlds IMHO. C syntax, but no C++ 'features'.

Seriously.  You can easily do Real OOP in C; the only thing it lacks
is syntactic sugar.  I wish there was a real C++, as in a C that has
just had a few minor, incremental improvements made to it.  C++ may
have a lot in common with C in a technical sense, but the mentality it
represents is almost completely orthogonal.  (And yes, you can write C
style in C++, but then, why not just use C?)

The D programming language looks very promising in this regard, but
its newsgroup faces a daily battle with people who seem more
interested in creating a religion than a tool.  Now that I think about
it, that struggle seems to be a recurring theme in the world of
programming languages at large.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] Re: mouse wheel behavior and RFC: human interface guidelines

[Pete Bessman]

At Sun, 22 Aug 2004 15:18:52 +0200,
Artem Baguinski wrote:
> 
> people do not need consistent experience, people need to get the work 
> done. consistency is one of the tools that make getting the work done 
> easier, but it isn't a goal in itself.

++kudos;

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines

[Pete Bessman]

At Sat, 21 Aug 2004 18:35:44 +0200,
Melanie wrote:
> 
> Left is generally associated with up, right with down, as we read
> left to right, top to bottom. Therefore, up MUST map to left, down
> MUST map to right, otherwise, non-mathematically minded people get
> uttely confused.

This is perhaps the archetypal example of how a useful concept (making
connections between the UI and the Real World) gets turned into a
religion at the expense of that which it putatively helps and the
profit of...

uh...

yeah.

There's too much of this everywhere, but the infection seems to be
particularly insidious in CompSci (I LOST 25 POUNDS IN TWO WEEKS WITH
OOP) and UI design (pixels, being small, become unusable in light of
Fitt's law; they MUST be discarded).

I guarantee you that the last thing on 99.8% of users' minds when
they're adjusting a horizontal volume slider is "This is kind of like
reading a book, which goes left to right and top to bottom; and if we
assume an association between beginnings and ends, then it follows
that left and up are vaguely synonymous.  Therefore, to decrease the
volume with my mousewheel, I MUST spin up."

Bah, humbug.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

P.S. Guess what profession/hobby the remaining 0.2% have.

Re: [linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines

[Pete Bessman]

I never noticed the behavior of horizontal scrollbars in GTK because
I've never encountered any.  Just checked out the behavior of
Rhthymbox's seek indicator, it's just as you described (i.e., dain
bramaged).  That's a bug, plain and simple.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

[linux-audio-dev] Re: [linux-audio-user] mouse wheel behavior and RFC: human interface guidelines

[Pete Bessman]

At Sat, 21 Aug 2004 01:30:59 -0400,
Lee Revell wrote:
> 
> What is really needed is a set of human interface guidelines for Linux
> audio apps.  Better to do this now, while much of the code is not
> mature, than later, and have a bunch of different apps which work,
> except that the widgets work completely different from one app to
> another for no good reason other than that person A felt like doing it
> like this and person B like that.  You can talk about freedom all you
> want but the users do not care about this kind of thing, it just looks
> like the left hand is not talking to the right.  Professional users
> (rightfully) demand a consistent interface, unless there is a good
> reason (extra functionality) not to provide one.

I definitely agree.  One of the main reasons PHAT was created was
to encourage standard behavior across apps.  I don't think folks
are terribly interested in actually getting this done, but it's
Really Important.

I'm all ears.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] [ANN] PHAT version 0.2.0

[Pete Bessman]

At Tue, 17 Aug 2004 16:11:07 -0400,
Dave Robillard wrote:
> 
> >  Sorry about the flicker, it doesn't happen when
> > dragging to the right or down;
> 
> It doesn't flicker, but the rightmost edge is really jumpy and glitchy
> looking.  Maybe add a bit of a horizontal threshold for resizing so it
> doesn't look so glitchy?

This is probably a good idea in general; I bet it would reduce the
flickeriness of the fans in general.  It's Thorsten's baby, so I want
to wait until he chimes in before moving forward.  However, I think if
the threshold is adjustable, this is a good feature to include.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] [ANN] PHAT version 0.2.0

[Pete Bessman]

At Tue, 17 Aug 2004 14:15:30 -0400,
Jesse Chappell wrote:
> 
> In fact the sliderbutton really just seems to lack the visual
> indication of "sliderness", and i think adding it as Dave suggested
> would be a good addition (or make a new widget).

I have no idea what you mean by lacking a visual indication of
sliderness.

None of this is the point of the sliderbutton.  I tend to think that
representing discrete numerical quantities (i.e. Channels 1 to 16) is
best done with the roman alphabet.

For the sliderbutton in graphical form with variable precision, check
the fansliders.  Sorry about the flicker, it doesn't happen when
dragging to the right or down; the problems with up and left are due
to (AFAICS) insurmountable problems with X11.  You can hold down ctrl
to freeze the fan at it's current size, which stops the flicker while
adjusting (also, shift freezes value adjustments so you can drag out
without screwing up the current value).

Basically, use the sliderbuttons when the number is important, use the
fansliders when it isn't.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] Read this after your first cup of coffee

[Pete Bessman]

votes++;

Caveat: for purposes of discussing this article and all it entails,
everybody falls into either the "I'm with it" or the "I don't care"
group (tautological, I know, but bear with me).  Both perspectives are
equally valid, and since they aren't mututally exclusive, let's be
nice to each other.

--Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] [ANN] PHAT version 0.2.0

[Pete Bessman]

At Tue, 17 Aug 2004 10:25:41 +0200,
Wolfgang Woehl wrote:
> 
> Pete Bessman <[EMAIL PROTECTED]>:
> > Ok, that function is new to gtk+-2.4.  I modified the relevant code
> > to omit that function call when on gtk+-2 systems < 2.4, and it
> > compiles fine on Fedora Core 1 with PlanetCCRMA now.
> >
> > www.gazuga.net/phat-0.2.1.tar.gz
> >
> > Let me know if this works for you.
> 
> Works, configure/make happy with 2.2.3 now. Thanks.
> btw: to demo the increase in accuracy for the horizontal fanslider as 
> well why not add a smaller horizontal?

Glad it works.  The demo has it's rough spots, but a dude's gotta have
priorities, right?  If you want to improve the demos, have at it (not
being a dick here, seriously), and if you don't know how to code,
they'd be a great place to get started :-D

--Pete

<http://www.gazuga.net>

"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] [ANN] PHAT version 0.2.0

[Pete Bessman]

Ok, that function is new to gtk+-2.4.  I modified the relevant code to
omit that function call when on gtk+-2 systems < 2.4, and it compiles
fine on Fedora Core 1 with PlanetCCRMA now.

www.gazuga.net/phat-0.2.1.tar.gz

Let me know if this works for you.

--
Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] [ANN] PHAT version 0.2.0

[Pete Bessman]

At Mon, 16 Aug 2004 10:47:53 +0200,
Wolfgang Woehl wrote:
> 
> Hi Pete, make stumbles over
> 
> phatsliderbutton.c: In function `phat_slider_button_init':
> phatsliderbutton.c:638: warning: implicit declaration of function 
> `gtk_entry_set_alignment'
> make[2]: *** [libphat_la-phatsliderbutton.lo] Error 1
> 
> Is that my box or is it phat?

Theoretically your box, specifically your GTK+ version.  That function
is defined in GTK+-2.0, but it might not have been introduced until
the recent 2.4 release, and you might be running the more popular 2.2.
This isn't noted in the developer docs, so I'm not sure.  I'll verify
this later today by seeing if I can compile on Fedora Core 1, which is
2.2 based.

--
Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

[linux-audio-dev] [ANN] PHAT version 0.2.0

[Pete Bessman]

Once again, I'm cross posting this to the users list in case anybody
is interested in fooling around with the demo apps.

I'm pleased to announce the release of PHAT, the Phat Audio Toolkit,
version 0.2.0.  PHAT is a collection of GTK+ widgets that may prove
useful to audio applications.

New to this release is a shameless ripoff of Blender's "sliderbutton"
widgets.  I like 'em more than regular GtkSpinButtons.  Also, there
have been sundry improvements to the fansliders, and all widgets are
now mousewheelable and focusable, and they respond to sensitivity
changes (i.e. they're well behaved).

After installing, you'll have two demo apps at your disposal:

phatsliderbutton
phatfanslider

(A few) more details are available at www.gazuga.net/phat.php

Enjoy.

--
Pete



"Nothing great was ever achieved by being realistic!" --Tom Venuto

Re: [linux-audio-dev] [ANN] PHAT version 0.1.0

[Pete Bessman]

At Mon, 2 Aug 2004 14:05:00 +0200 (CEST),
Kjetil Svalastog Matheussen wrote:
> 

> > There have been some drawing errors happening 
> > when moving the fan out to one side and then 
> > the other in one go. But they are actualy hard 
> > to trigger, so please stress test the demo and 
> > report to Pete, so we might find out where the 
> > problem lies.
> > 
> 
> I can't trigger that, but the flickering is annoying.
> How about double-buffering the thing?

This isn't anything that can be helped, AFAIK.  The thing *is* double
buffered.  If you drag to the right, or down, you'll notice that it's
smooth.  The problems only occur when you drag to the left, or up.
This is because I have to constant move the window (flickery) and
apply a new clipping mask (even more flickery).  If there's a way to
make this look nice, it is currently lost on me.

-- 
Pete

www.gazuga.net

=
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:

* The title."

[maddox.xmission.com]
=

Re: [linux-audio-dev] [ANN] PHAT version 0.1.0

[Pete Bessman]

At Sun, 1 Aug 2004 13:54:50 +0200,
Jan Weil wrote:
> 
> On Sat Jul 31 21:39:51 2004 Pete Bessman wrote:
> > I'm pleased to annouce, after a solid month of heated debate with
> > X11, the initial public release of PHAT, the PHat Audio Toolkit.
> > From the website (www.gazuga.net/phat.php):
> 
> I tried the demo and I like the concept of the fanslider.

Cool, glad you like it.

> Did you think about displaying the current value in the fan?  With
> the demo it is easily possible to move the fan over the spinbuttons
> which hides your feedback and makes it impossible to control the
> exact value.

I did, but I think this information is better left to the app's
discretion.  To provide sufficient flexibility for value display
(location, format, prefix) would require much added API complexity,
and the end result would be less useful than simply writing custom
callbacks.

And personally, I think the cleanest way to display such information
is in a statusbar, or perhaps a tool tip.  I also don't see the
usefulness of exposing values to the user in an audio app (generally).
Panning might be stored as an excess-127 unsigned char, or a [-1.0,
1.0] float, or a LUT index, or a percentage.  I, as a user, don't
care; just so long as panning follows the slider position I'm happy.

I'm not opposed to this feature being implementing (just so long as
it's done well, and if you don't use it it's not there).  However, I'm
not going to be doing it myself, at least not any time soon.

-- 
Pete

www.gazuga.net

=
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:

* The title."

[maddox.xmission.com]
=

Re: [linux-audio-dev] [ANN] PHAT version 0.1.0

[Pete Bessman]

At Sat, 31 Jul 2004 23:58:23 -0400,
John Check wrote:
> 
> Okay, the question is, does this exist on Windows or Mac?
> This would also be killer on a touch screen BTW.

I dunno, I have neither.  The only dependency is GTK+ and the a GNU
build environment.  Since GTK+ runs on Windows and Mac, I imagine PHAT
would as well.  However, I'm a Linux bigot, so I can't confirm this.

--
Pete

www.gazuga.net

=
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:

* The title."

[maddox.xmission.com]
=

Re: [linux-audio-dev] [ANN] PHAT version 0.1.0

[Pete Bessman]

At Sat, 31 Jul 2004 22:14:18 -0400 (GMT-04:00),
Taybin Rutkin wrote:
> 
> Sounds neat.  Are there any screenshots?

Ask and ye shall receive:

http://www.gazuga.net/fanslider.png

John Check's message later on shows that the widgets are drawn
thematically.

-- 
Pete

www.gazuga.net

=
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:

* The title."

[maddox.xmission.com]
=

[linux-audio-dev] [ANN] PHAT version 0.1.0

[Pete Bessman]

I'm pleased to annouce, after a solid month of heated debate with X11,
the initial public release of PHAT, the PHat Audio Toolkit.  From the
website (www.gazuga.net/phat.php):

"PHAT is a collection of GTK+ widgets geared toward pro-audio
apps. The goal is to eliminate duplication of effort and provide some
standardization (well, at least for GTK+ apps). It's open source
software, licensed under the GNU GPL, version 2.0 or later."

The debut and flagship widget is the fanslider, designed by Thorsten
Wilm's.  The LAU folks may not be too interested in the library as
such, but might like to play around with this widget (hence the cross
post).  It comes with a demo program, "phatfantest," which displays
the sliders in all their glory.

Tarball: www.gazuga.net/phat-0.1.0.tar.gz

Docs: www.gazuga.net/phat/index.html

Let's actually go somewhere with all this debate about widgets and
standards and such.  Contributions are welcome (hint hint).  I hope we
can put an end to the Linux Usability Curse, at least in our own
little neck of the woods.

--
Pete

www.gazuga.net

=
"I saw the movie 'I, Robot' recently, a film based loosely on a book
written by science fiction author Isaac Asimov. In case you're not
familiar with Asimov's writing, here's a list of things the movie had
in common with the book:

* The title."

[maddox.xmission.com]
=

Re: [linux-audio-dev] Traps in floating point code

[Pete Bessman]

At Wed, 30 Jun 2004 16:37:59 +0100 (BST),
Mike Rawes wrote:
> 
> --- Pete Bessman <[EMAIL PROTECTED]> wrote: 
> > At Mon, 28 Jun 2004 19:56:50 +1000,
> > Erik de Castro Lopo wrote:
> > > 
> > > double fractional = 0.0, increment = 0.1;
> > > int integer = 0;
> > > 
> > > for (;;)
> > > {   
> > > /* Bunch of other code. */
> > > 
> > >   fractional += increment ;
> > > integer += lrint (floor (fractional));
> > > fractional -= floor (fractional);
> > > }
> > 
> > I don't understand this lrint (floor ()) stuff.  floor() returns a
> > truncated integer value, so what's the point of calling lrint() on
> > that?
> 
> The lrint converts the float value to an int (a lot) faster than a
> simple cast.

Ah.  Now I get to find all the places in my code that can benefit from
that.  If you assign a float value into an int variable, is that an
implicit cast?

> The floor is to get around the rounding rule used by the FPU when the float
> value is exactly halfway. It rounds to even numbers, at least it does on an
> AthlonXP:

Good to know, thanks for the tip.  Although, just using lrintf(val)
would be wrong anyway because it would round up if fmod(val, 1.0) >
0.5, right?

-Pete

www.gazuga.net

Re: [linux-audio-dev] Traps in floating point code

[Pete Bessman]

At Mon, 28 Jun 2004 19:56:50 +1000,
Erik de Castro Lopo wrote:
> 
> 
> People who play around with floating point code (especially on x86)
> quickly learn about the evils of comparing the equality of one floating
> point value with another. 

I got my first lesson just a couple of days ago, in fact.  Gave me all
the encouragement I needed to learn assembler.

On a similar note, I remember when I was just starting out, and was so
new to C that I didn't even know sprintf existed, I wrote a naive
float-to-string conversion routine.  I was encountering the
*strangest* problems; certain digits would come out either one step
higher or lower than they should have.

Turns out this was a number theory problem (didn't know what that was
at the time, still not sure I do).  My algorithm would divide the
input number by 10 repeatedly until the results was less than 10.  It
would then convert the integer value to a character, subtract the
integer value from the float value, then multiply the float value by
10 and repeat until done.

Now, if computers operated on a base 10 system this would've been fine
and dandy, since every digit could be cleanly represented when divided
by 10.  However, the only decimal fraction you can represent cleanly
in binary is 0.5 (comes out as 0.1 in binary).  Everything else
results in a repeating fraction, and good luck figuring out what
you'll wind up with when you multiply that by 10 to make it an
integer.

There is *many* a slip betwixt the cusp and the lip.

> double fractional = 0.0, increment = 0.1;
> int integer = 0;
> 
> for (;;)
> {   
> /* Bunch of other code. */
> 
>   fractional += increment ;
> integer += lrint (floor (fractional));
> fractional -= floor (fractional);
> }

I don't understand this lrint (floor ()) stuff.  floor() returns a
truncated integer value, so what's the point of calling lrint() on
that?  Why wouldn't integer += fractional suffice?  A corollary of
this is that I don't understand the problem...

> The fix in this case was this:

...and a corollary of the corollary is that I don't understand the 
fix :-\

-Pete

www.gazuga.net

Re: [linux-audio-dev] Knobs / widget design + some OT stuff

[Pete Bessman]

At Sun, 27 Jun 2004 23:03:15 -0400,
Pete Bessman wrote:
> 
> That's a straw man.  The original point was something to the effect
> of "a volume knob which can only be operated after studying a manual
> is an indication that the UI designer is a failure," although my
> rendition is probably more caustic than the original.

So it seems it wasn't clear that the above was a humorous jab, not
meant to be taken seriously.  My bad.  My sense of humor must be
"special."

This *was* a debate about the performance requirements of Thorsten's
fan sliders.  I personally think that machines which can't deal with
the sliders would be better off running trackers; high-end audio
already comes with a high-end performance tag (relatively speaking),
and if you can afford a 1Ghz/512MB system, you can afford a GPU.
Really, you can:

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&category=40160&item=5103986172&rd=1

The argument got "ugly" when Fons took a point of Thorsten's out of
context (if you define "ugly" as the point at which I got pissed and
started flinging argumentum ad hominem).  "Requiring the user to read
documentation to learn about functionality he would not even expect is
not an option," is clearly wrong on a general level.  Therefore, Fons
is technically right; the only way such a requirement could exist is
if the human desire for knowledge has dropped to a pathologically low
level, either from lack of education (*snort*) or other causes.

However, the point is clearly right as it applies to the fan sliders.
A user with an IQ >= 100 shouldn't need to consult a manual to spin a
knob or flip a switch, and if you think otherwise you should bar
yourself from participating in UI discussions.

Skewering a point on a literal and pedantic level is a sure-fire way
to get labeled an elitist.  Moral of the story: make a snide and
barely on topic remark, get a face full of flame.

--
Pete

www.gazuga.net

Re: [linux-audio-dev] Knobs / widget design + some OT stuff

[Pete Bessman]

At Mon, 28 Jun 2004 01:22:05 +0200,
Fons Adriaensen wrote:
> 
> "... whenever we invite someone into the news studio, he has to make
> his point in 12 seconds. If I know he can't, I will not even
> consider him." Why not ? "Beacause it's bad TV, and our market share
> will go down. Our viewers just don't want to concentrate on any
> issue, they want to be entertained. Anyway that's what our
> advertisers tell us: we want the largest segment, which are the
> people who don't want to think or do any other mental effort."
> 
> This is just one of the many things I learned over the last years,
> and which all point into the same direction: the main social
> dividing line in most western societies these days is one that
> reflects education levels. It determines lifestyle, consumption
> patterns and political preferences, and it is much more influential
> than financial status or the old social classes.

Your insinuation that those with a higher level of education aren't
susceptible to the 12 second attention span problem (for the record,
you and I at least agree on the fact that it *is* a problem) doesn't
hold water.  At least in the United State of Maryland, most
institutions of higher learning that offer an on-campus living
solution also offer a cable TV package (MTV included); if there was no
demand, there would be no supply.

Your point is an anecdotal non-sequitur anyway, although it does
reinforce opinions of your elitism (well, at least my own).

> More and more, as an 'intellectual' I find myself in a position that
> comes down to this: either you budge and dumb down, or you'll be
> excluded. This is just one step from what happened during the Nazi
> regime, the 'Cultural Revolution', or the Pol Pot government, where
> everyone who dared to think was just eleminated.

http://info.astrian.net/jargon/terms/g/Godwin_s_Law.html

> Going back to our original point: if a user is too lazy to read a
> manual, I can't be bothered with his problem. And if someone
> proclaims that aversion to reading documentation is 'normal', I will
> disagree, and now you all know why.

That's a straw man.  The original point was something to the effect of
"a volume knob which can only be operated after studying a manual is
an indication that the UI designer is a failure," although my
rendition is probably more caustic than the original.

-Pete

www.gazuga.net

Re: [linux-audio-dev] Knobs / widget design (radial movement)

[Pete Bessman]

At Sat, 26 Jun 2004 09:36:26 +0200,
Fons Adriaensen wrote:
> 
> What is "normal" ?

Why do you think I put it in "quotes?"

> I have an increasing difficulty in just understanding what you try
> to say. Could you explain the terms

No.

> - crow-magnon (sic) music

I'm amazed that your purportedly scintillating perspicacity couldn't
detect the humor here.

> Where is the criticism ? 
> Where is the sneer ?
> 
> I made the observation that educated people usually do not mind
> having to learn something. So if there is a widespread aversion to
> having to learn and read a manual, that seems to indicate that
> education levels have gone down.

Great, well, I made the observation that the intelligentsia have
microscopic genitalia. (What, you want my data? Surely you jest.)
Ergo, the smarter a person claims to be, the greater the magnification
they require at the urinal.

Really.  Perfectly level-headed, no sneering or contempt here.  Just
an honest attempt at productive discussion.

-Pete

Re: [linux-audio-dev] Knobs / widget design (radial movement)

[Pete Bessman]

At Sat, 26 Jun 2004 01:41:17 +0100,
Dave Griffiths wrote:
> 
> "I HAVE to understand everything about an interface in 5 SECONDS!"
> attitude to gui design. People can learn things, it's part of
> playing music on real instruments - why can't it be part of playing
> computer instruments?

I simply don't believe in making things arbitrarily difficult, so long
as the thing in question is a tool.  This mentality is actually
reflected in real instruments; they are as simple as possible, but no
simpler (i.e., to the point of removing functionality).  There's isn't
any benefit to be had by putting the pedals on the backside of the
piano.

I further believe that this school of thought actually enables the
creation of more unique music than otherwise.  A guitar is, from a
usability point of view, self explanatory.  After a few minutes of
fooling around, you'll understand how it works (you'll still suck,
however).  After a few *years* of fooling around, you'll discover
two-handed tapping.  Similarly, a software instrument designed with an
intuitive UI will make it easier for the user to put things together
in unexpected and intriguing ways, since mental resources aren't being
diverted to rudimentary actions that could be made trivial.

-Pete

Re: [linux-audio-dev] Knobs / widget design (radial movement)

[Pete Bessman]

At Fri, 25 Jun 2004 23:28:35 +0200,
Fons Adriaensen wrote:
> 
> > so that I can compare it against the mouth-breathing crow-magnon
> > music created with shiny-quarter interfaces.  I'm sure the results
> > will speak for themselves.
> 
> They do, but maybe not in the direction you imagined. And cro-magnon
> times are well in the past.

I'm lead to believe it would be in the *exact* direction I predicted.
Avant garde on the one hand, "normal" on the other.

If you like avant garde, and you prefer avant garde tools and lean
interfaces, that's 100% A-OK.  But your particular preferences do not
render your criticism objective (or useful).  A sneer is a sneer, and
if that's all you have to add, your input is worthless.

-Pete

Re: [linux-audio-dev] Knobs / widget design (radial movement)

[Pete Bessman]

At Fri, 25 Jun 2004 18:00:42 +0200,
Fons Adriaensen wrote:
> 
> On Fri, Jun 25, 2004 at 06:54:20PM +0200, Thorsten Wilms wrote:
> 
> > Requiring the user to read documentation to learn about
> > functionality he would not even expect is not an option.
> 
> Have education levels gone down *that* far ?

WTF?  Dude, that is messed up.

"Clearly these are inferior organisms.  They demand that the volume
knob be usable without first consulting a manual!  I shall now program
PD to kick them in their mongoloid crotches."

Dave Griffiths said something above about "hiding functionality for
the users to find."  That, to, is just wrong.  This isn't a videogame
or Where's Waldo.  Not that I have anything against easter eggs, but I
don't think basic functionality should be hidden a priori.

I have a very simple request for everybody who loathes
"plug-and-drool" usability: show me the tunes.  That's all.  Lemme
hear the avant garde music enabled by avant garde interfaces so that I
can compare it against the mouth-breathing crow-magnon music created
with shiny-quarter interfaces.  I'm sure the results will speak for
themselves.

-Pete

[linux-audio-dev] [ANN] Specimen 0.4.0 "Smooth"

[Pete Bessman]

Specimen is a MIDI controllable SoftSampler for GNU/Linux systems.
Features added since 0.3.0 include:

* Portamento

* Per-parameter LFOs with delay and attack

* LFOs may be "global" (voice independent) or per-voice

* LFOs may be constrained to oscillate between 0 and 1 instead of -1
  and 1

* ADSRs have gained delay and hold phases

* Most parameters can be velocity sensitive to a user-specified degree

* LFO/ADSR amounts for pitch are now entered in half-steps

* A sample's pitch may be adjusted within a user-definable range

You can download the latest tarball (some assembly requried) from
www.gazuga.net, or directly below:

http://www.gazuga.net/files/specimen-0.4.0.tar.gz

The focus of the 0.4.x series is the GUI, so if you've got a gripe or
a wish about that, now's the time to pipe up.  As always, my inbox is
wide open to suggestions and bug reports.

-Pete

Re: [linux-audio-dev] Spinboxes

[Pete Bessman]

At Sun, 20 Jun 2004 18:16:54 +0200,
Thorsten Wilms wrote:
> 
> The usual spinboxes with their tiny up/down arrow buttons made me
> think about an alternative.  Since using more height than a
> textfield has would make layout very troublesome, my solution is
> placing the buttons horizontaly.

I think you are *really* on to something here.

> I think the variations with arrows are less pleasant to look
> at. Using - and + also avoids confusion with option menus. But I
> would like to hear everyone's opinion on that.

I prefer -/+ myself, it seems easier to assess at a glance.

> I don't know if showing the value as bar in the background is a good
> idea in the end, because it might be confusing (?)

Perhaps hiding the numbers, and only showing them if the user mouses
over the texbox or clicks on it?

I definitely think these are a major improvement over spinbuttons as
far as audio apps are concerned.  My only question is if they're
superior to traditional knobs/sliders.  I think the only way to tell
would be to implement and compare.

-Pete

Re: [linux-audio-dev] Multithreaded programming for a poll model?

[Pete Bessman]

At Thu, 17 Jun 2004 12:50:06 +0200,
Mario Lang wrote:
> 
> I am currently trying to figure out how to restructure the code
> of my little yatm tool to be flexible and extensible in the future.
> Basically, I'd like to be able to become a JACK client at
> some point in the future.  Since JACK uses a poll model, I have
> to majorly restructure my code. I think what I need is the following:
> Three threads, one for the UI, one for the MPEG/Vorbis/Speex decoder,
> and one for audio output (to either libao or JACK).

You actually probably only need two threads, one for the UI and one for
audio (more on this below).

> Additionally, I'd like to have the ability to make the
> buffer in between remember the last n seconds of audio data and make
> it possible to jump back in time <=n seconds during playback.

I think you could just change the value of the position indicator to
have it point that many frames back in time.

> I've looked at the lock-free ringbuffer of JACK, but I am not
> sure if this is really what I need here.  

The lock-free ringbuffer is necessary to communicate to the audio
thread in an RT-safe manner.  RT doesn't really mean "goes fast" so
much as it means "has a guaranteed minimum speed."  If you communicate
with the JACK thread just by mutex-protected global variables, that
guarantee becomes difficult to make.  This is because the JACK thread
will have to lock each mutex to check the value, and there is a
possibility that it might end up waiting an indeterminate amount of
time to get that lock if your UI thread has it.  If you use multiple
variables protected this way, things get worse.

So basically, if you need to tell your JACK thread something, you need
to do it with a ringbuffer.

What I'd recommend doing is creating a UI thread and having it
communicate to the audio thread via the ringbuffer.  The audio thread
would have some setting indicating a chunk of memory or file
(whatever) to read sound data from, in addition to settings on how to
read it and where it currently is within the file.  You would adjust
these settings by checking for messages from the UI in the ringbuffer
at the beginning of each callback invocation.

After checking for messages, just mixdown the number of frames
requested into the provided buffer, transforming it in accordance with
thread's current settings.

Hope that helps,

-Pete

Re: [linux-audio-dev] FYI (FW: [The end of an era])

[Pete Bessman]

At Tue, 15 Jun 2004 22:08:07 +0200,
Claudio Mettler wrote:
> 
> On Tue, Jun 15, 2004 at 02:26:05PM -0400, Pete Bessman wrote:
> > At Tue, 15 Jun 2004 17:43:33 +0200,
> > Claudio Mettler wrote:
> 
> UH! That wasn't me who wrote this. I didn't write this plugins. I'm
> just the guy who forwarded this mail which was sent to the music-bar
> (ampfea.org) Mailinglist.

AACK!

> > > I just released the source code to my plugins which I recently stopped
> > > developing:
> > > 
> > > http://www.bioroid.com
> > 
> > Grammercy!  Leeched for future use, thanks for the contribution :-)
> 
> From:
> "Martin Robaszewski" <[EMAIL PROTECTED]>   <- thank him ;)

OK, he's been thanked.

Man, some days...

me < all

-Pete

Re: [linux-audio-dev] FYI (FW: [The end of an era])

[Pete Bessman]

At Tue, 15 Jun 2004 17:43:33 +0200,
Claudio Mettler wrote:
> 
> I just released the source code to my plugins which I recently stopped
> developing:
> 
> http://www.bioroid.com

Grammercy!  Leeched for future use, thanks for the contribution :-)

-Pete

Re: [linux-audio-dev] linux use (was [OT] marketing hype)

[Pete Bessman]

At Sat, 12 Jun 2004 17:20:27 -0400,
Dave Robillard wrote:
> 
> On Fri, 2004-06-11 at 07:21, Tim Orford wrote:
> > me too, but i'm currently very motivated to code, _if_ i could find
> > something to work on.

[snip]

> I all seriousness though, maybe it would be a good idea to create a
> centralized list of apps that need to be written?  Kind of a global
> linux audio TODO list.
> 
> We could even put enhancements to existing software there as well (ie
> "add LASH support to ZynAddSubFx" etc.)

votes++

On another note, if you're feeling motivated to do anything, consider
writing docs.  Before I started developing, I never understood
why developers write crummy docs, or don't write them at all.  Now
I "get it."  Complete and utter lack of time.  So if you *really*
want to help, writing docs would elevate you to Zeus-like status
in my eyes ;-)

-Pete

Re: [linux-audio-dev] GThread vs. pthread

[Pete Bessman]

At 12 Jun 2004 00:09:05 -0500,
Jack O'Quin wrote:
> 
> Pete Bessman <[EMAIL PROTECTED]> writes:
> 
> > One more point in favor of GThread I just figured out is config
> > testing for it.  All you have to do is at a pkg-config check for
> > gthread-2.0 and your set.  Having glanced through other programs,
> > checking for pthreads seems a bit more involved than I care to be
> > (read: not at all, I hate the fscking autotools).  So, I think
> > I'll roll with GThread.
> 
> Not a very strong reason.  Checking for pthreads is a little tricky,
> but hardly rocket science.  These checks (from JACK) work for quite a
> few platforms, though I'm sure there are others one could add...
> 
> AC_CHECK_HEADER(/usr/include/nptl/pthread.h,
>   [CFLAGS="$CFLAGS -I/usr/include/nptl"])
> 
> AC_CHECK_FUNC(pthread_create, [],
> AC_CHECK_LIB(pthread, pthread_create, [],
>   AC_MSG_ERROR([*** JACK requires POSIX threads support])))

Touche.  Since you did all the hard work for me, and pthreads isn't
OOPy like GThreads, I'll stick with pthreads :-)

> There is also a conditional check for pthread_barrier_init().

Well, I don't even know wtf that is, so I think I'll be ok without it.

[pb]

[linux-audio-dev] [ANN] Specimen 0.3.0 released

[Pete Bessman]

The latest release of Specimen, a midi controllable audio sampler for
Linux, adds 4 LFOs which can modulate volume, panning, cutoff and
resonance into mix.  Additionally, the LFOs can be tempo synced to
either midi or the jack-transport mechanism.

Available for immediate leeching from www.gazuga.net, or
you can download the tarball directly here:

http://www.gazuga.net/specimen-0.3.0.tar.gz

I'm working on a roadmap for Specimen, and I'm interested in hearing
what features people are most interested in having.  If there's
something you want Specimen to do, let me know; the most popular
features will get incorporated first.

[pb]

Re: [linux-audio-dev] GThread vs. pthread

[Pete Bessman]

At Sat, 12 Jun 2004 00:10:17 -0400,
Paul Davis wrote:
> 
> >Does anybody have any opinion on which threading system is superior?
> >I've been using glib for a lot of things, but for whatever reason I'm
> >hesitant about using it for threading if the only benefit it will
> >provide is consistency (I'm guessing it's just a wrapper for pthread
> >anyway).
> 
> yes, its just a wrapper. there's nothing in the semantics of GThread
> that isn't present in pthreads; conversely, pthreads does have a few
> corners here and there that GThreads don't wrap because they don't
> exist in some of the other thread systems that GThreads
> supports. you're unlikely to need them. personally, i prefer to use
> pthreads because its a fully specified standard that is independent of
> any particular platform. otoh, there is a very similar argument for
> GThread.

One more point in favor of GThread I just figured out is config
testing for it.  All you have to do is at a pkg-config check for
gthread-2.0 and your set.  Having glanced through other programs,
checking for pthreads seems a bit more involved than I care to be
(read: not at all, I hate the fscking autotools).  So, I think
I'll roll with GThread.

Thank you much for chiming in on this.

[pb]

[linux-audio-dev] GThread vs. pthread

[Pete Bessman]

Does anybody have any opinion on which threading system is superior?
I've been using glib for a lot of things, but for whatever reason I'm
hesitant about using it for threading if the only benefit it will
provide is consistency (I'm guessing it's just a wrapper for pthread
anyway).

[pb]

Re: [linux-audio-dev] Knobs / widget design

[Pete Bessman]

At Thu, 10 Jun 2004 12:50:19 +0200,
[EMAIL PROTECTED] wrote:
> 
> i dont see a problem. there is knob code for every toolkit on
> sourceforge. lets unify the gfx data have a widget for every toolkit.

votes++

[pb]

Re: [linux-audio-dev] [OT] marketing hype

[Pete Bessman]

At Wed, 09 Jun 2004 19:40:44 -0400,
Dave Robillard wrote:
> 
> If you want a plug-in-and-drool computer, you're not running the
> right OS.

/me scratches head

if (plugin_and_drool == JUST_WORKS)
buy (plugin_and_drool);

Point being, just because something is hard to use doesn't mean it is
superior in *any* way to something which is easy to use.

> -DR- (Who debated hitting "send" on this one for a good 5 minutes)

Should have waited longer.  Marek wasn't telling anyone to become his
personal code-bitch, and if you were truly apathetic to his plight
a simple "I don't care" would suffice.

Marek, I think you'll be surprised at how many "I don't care" + flame
responses you're going to get.  I, for one, do care.  I want to make
money writing libre software, so I'm all ears to your suggestions.
But remember that if you can't put up, you'll be well advised to shut
up 'round these parts.

OH, since likely nobody knows, I'm the guy that's writing Specimen.

[pb]

Re: [linux-audio-dev] [OT] marketing hype

[Pete Bessman]

At Wed, 09 Jun 2004 17:07:35 -0500,
Jan Depner wrote:
> 
> I also doubt if there is a single developer in the Linux Audio
> Developer community who could accurately be described as inept.

Good, so I haven't been found out yet.

[pb]

Re: [linux-audio-dev] Re: UI stuff

[Pete Bessman]

At Tue, 08 Jun 2004 16:50:40 -0500 CDT,
Ben wrote:
>
> The app "Soundplay" for BeOS takes a novel approach ... the level is
> shown as a knob but when you grab it, a rectangular box appears
> behind the knob and you adust it like a fader.  This is great
> because it gives you visual feedback of which direction(s) to move
> the knob.

votes++

Re: [linux-audio-dev] Is ladspa actually la-dsp-a? Is JACK the ultimate solution?

[Pete Bessman]

At Wed, 09 Jun 2004 10:10:22 +0200,
Jens M Andreasen wrote:
>
> Last time I checked, rivers flew from the top of the mountains, thru the
> valleys below, and out in the ocean. Even in China :)

In Soviet Russia, river flows through YOU!

[pb]

[linux-audio-dev] [ANN] Specimen 0.2.9 Released ("I'm Not Dead Yet")

[Pete Bessman]

Howdy folks!

The newest version of Specimen is available for immediate download from
www.gazuga.net (direct: http://www.gazuga.net/specimen-0.2.9.tar.gz).
Features include:

* A piano for graphically asigning note ranges

* A very happenin' bank building interface that uses an embedded File
  Chooser (gtk+-2.4 required for this)

* LASH/LADCCA support

* Extensive repairs, most notably to the waveform display (it's alias-
  free) and the panning code (it works).

* A completely revamped audio rendering system

* Sundry cleanups and fixes

Many thanks to Loki Davison, the new and official co-developer, for his
fabulous contributions to this release, and for bitch-slapping me into
getting back to work on this code (rather than piddling around with
vaporware).

Stay tuned for more...

[pb]

--
"The direct use of physical force is so poor a solution to the problem of
limited resources that it is only employed commonly by small children and
great nations."
--David D. Friedman

Re: [linux-audio-dev] MuSE 0.9 codename "COTURNIX" - out now with documented API!

[Pete Bessman]

At Mon, 19 Apr 2004 07:55:59 +0200,
Robert Jonsson wrote:
> 
> There is an unfortunate fact in that there are TWO muse projects,
> differing only in the use of capital letters.

I was staring at the webpage for a full ten minutes before I realized
what was going on.  MusE with a GTK-2 interface?  What?

Uncool.  Somebody should rename their project to "The Project Formerly
Known as Muse," or perhaps some sorta whiz-bang symbol.

[pb]

Re: [linux-audio-dev] [ANN] First public release of Lindrum v 0.5.1

[Pete Bessman]

At Tue, 2 Mar 2004 01:19:00 +0100,
Peter Eschler wrote:
> And yes: I looked into hydrogen code. To learn. I looked into lot of
> little projects code. Dead projects. To learn. And IMHO they're not
> useless. Maybe my project will be dead at the end of the year. But
> then i made my experience and still can join hydrogen or other
> projects.

www.gazuga.net

;-)

[pb]

[linux-audio-dev] ANN: Specimen v0.2.1 released

[Pete Bessman]

I almost wanted to call this 0.3.0, but it's not quite there.  This
release adds a filter with resonance, ADSR volume envelopes,
independent direction and duration play mode configuration, and a
highly optimized resampling routine that easily accomodates 64 note
polyphony on my Athlon 1.33.

www.gazuga.net, as usual, has the latest.

I'm also going to dry and address the gazillion loose ends in that
other thread (I can't keep up with it anymore, so here's a fresh
start).

Patrick: There is no .glade file.  All the UI code was written by
hand, and as I said before, I highly dependent on the patch
infrastructure having a certain interface.

Jan: Coding gui events over ports does not sound like my cup of tea.
That would also be a pain since that is radically different from what
my gui code currently does.

Dave: I agree with all those features, they are on their way.  I just
have to take care of the basics first.

Steve: Nice to able to express a good old fashioned dissonant opinion,
thanks for granting me that slack.

Everybody: Perhaps I should emphasize a few facts:

a) Specimen is a few months old.
b) Specimen is my first real program.
c) Every day I sit down and code, I churn out around 500 to 1000 lines.
d) I intend for Specimen to be a professional quality music maker.

Granted, I haven't written design documents and such about how
Specimen will be professional, but that's mainly because I've been
spending my time working on the actual program.  It won't be more than
a couple more months before the vast majority of features necessary
for making rich music are available.  I also have no experience
with hardware samplers, my old instrument of choice was FruityLoops,
so I'm not thinking in terms of the way Real Samplers work.  I'm
trying to make a tool that makes music with the best possible
tradeoff between flexibility and ease of use, and maximal quality
all around.

OK, I've donned my asbestos armor, let 'er rip.

[pb]

Re: [linux-audio-dev] Some music made with Linux

[Pete Bessman]

At Fri, 20 Feb 2004 18:23:52 +0100,
David Olofson wrote:
> 
> > Tricky. To get crunchy hard-rock guitar sounds like Pete's
> > (nice track pete!), you'll have to realistically emulate
> > palm-muting, which I've never heard in a synth. And how would you
> > control the amount of muting? Map it to a CC and play a slider?

Don't think realistic.  Think like a synth.  If I was a synth, how
would I play guitar?  Why, I used a small sample of a guitar waveform,
run it through even more distortion and a harmonic generator, add
lowpass filter sweeps whenever I wanted to palm mute, etc...  The goal
is not to capture the sound of the guitar, but the _emotion_ of the
guitar, and to infuse it with the soul of the synth.

[pb]

Re: [linux-audio-dev] Some music made with Linux

[Pete Bessman]

At Thu, 19 Feb 2004 23:23:39 +0100,
David Olofson wrote:
>
> That said, it might be an interesting excercise to remix your song
> using only or mostly script based sounds... (Modular synthesis,
> basically.)  Dunno if there's much point it trying to synthesize the
> guitar riffs at this point, but I'll try all sorts of instruments
> eventually. There are a few synthesis operators and features I want
> to add first, though.

Writing a guitar sound synthesizer that sounds good is a very
difficult thing.  The best one out there (the proprietary Slayer
generator) sounds pretty crummy.  Since this song is industrial, and
the main gist of it is just a few guitar chords, using just a few
samples of the guitar sounds and some creative song restructuring
could produce excellent results.

So, if Audiality has or will have a sample player, I would use that
for the guitar sounds (I'd be happy to provide clips).  Otherwise,
instead of trying to synthesize guitars, just come up with really
gritty in face-melting synth sounds and use some of the aforementioned
"creative song restructuring."  

I don't know what your music hook up is like, but I would highly
recommend listening to the sounds on "Exiled on Mainline" by Chemlab
and "Edgecrusher (Urban Assault Mix)" by Fear Factory.  I further
recommend comparing the Fear Factory song against the original version
to see how far "creative song restructuring" can get you.

Whew, that was long winded!

[pb]

Re: [linux-audio-dev] Some music made with Linux

[Pete Bessman]

At Thu, 19 Feb 2004 19:42:05 +0100,
David Olofson wrote:
>
> Nice! Makes me wanna' play some violent first person shooter game or 
> something, for some reason... ;-)

I seem to recall seeing you on the libsdl lists back in the day (read:
last year).  If you're involved with a game that needs music, or know
of one, this is track is up for grabs.

[pb]

[linux-audio-dev] Some music made with Linux

[Pete Bessman]

Hi all,

Check out http://www.soundclick.com/bands/8/eastsidemilitiamusic.htm

After getting Specimen to an acceptable state, I threw together this
proper demo.  It has no vocals since me and my larynx don't get along,
but I encourage anyone who so desires to rectify that deficiency.

I used Seq24 for MIDI sequencing, Specimen for sampling, and Ardour
for recording.  Except for the guitars, everything in this song was
produced by Specimen+Seq24.  Someone on this list asked me to keep a
detailed journal of the process by which I created this (unfortunately
I can't remember who).  Well, as far as the Linux side of things goes,
it's not very interesting.  I used the aforementioned tools in a
typical fashion.  For general recording, any account I have to write
would be duplication of effort.  Instead, check out:


http://www.tweakheadz.com/guide.htm

Oh, and give the song a listen beyond the cheesy introduction.  That
part is meant to sound cheesy.  If the rest of the song sounds cheesy,
then I'm a failure, but have patience with the intro ;-)

[pb]

[linux-audio-dev] ANN: Specimen Version 0.2.0 Released

[Pete Bessman]

The second major of version of Specimen has been released today.  The
main change is the new sample editor that allows you to fine tune the
way your samples are being played.  I've also created some
documentation, and added ping-pong and reverse play modes.

Download it from www.gazuga.net, and read up on it at
www.gazuga.net/guide.

[pb]

[linux-audio-dev] Ann: Specimen v0.1.0 (the first beta release)

[Pete Bessman]

Too everyone who's waited with bated breath for this day to come
(primarily me), rejoice in the first beta release of Specimen, a midi
controlled audio sampler for GNU/Linux systems.  

Features as listed on the webpage:

# ALSA sequencer interface support.
# Audio output via ALSA or JACK.
# Individual panning and volume controls for each patch.
# High quality cubically interpolated pitch scaling.
# Sample start/stop and loop points.
# Three playback modes; "normal" just plays the sample, "trim" plays
  the sample and stops early if so instructed, "loop" plays the sample
  for the requested duration.
# Patch bank saving and loading in the "beef" file format.

Check out www.gazuga.net for more and to download the source.  I'm
gonna spend the next few days giving the program a usability test and
creating a demo song that does it justice, so keep your ears open for
some homegrown UHB in the not-too-distant future.

[pb]

[linux-audio-dev] ANN: Specimen Version 0.0.3 Released

[Pete Bessman]

Guess what?


...*chirp*...*chirp*...


Right, well... Specimen is midi controlled audio sampler for GNU/Linux
systems, and this is a new release of it.  I'm justifying this on the
inclusion of velocity sensitivity, cuts, and proof-of-concept (read:
crappy) pitch scaling.

You can download the newest tarball, check out the new screenshot, and
listen to the _fearsome_might_ of Specimen at www.gazuga.net.

[pb]

Re: [linux-audio-dev] New name for ladcca: LASH

[Pete Bessman]

At Tue, 20 Jan 2004 21:54:41 +,
Bob Ham wrote:
> Just to let you know I decided on LASH, which stands for 'LASH Audio

w00t.  I take all the credit, because I rule.

/me hides

> Session Handler'.  The recursive 'L' is because I've never felt
> particularly bound to linux *cough*hurd*cough*.  API, website and

You too eh?  I tried it a ways back, but I'm not an OS hacker (at the
moment) and it isn't to well suited to what I do.  I hope they get it
together, it would be rather cool

[pb]

Re: [linux-audio-dev] New name for ladcca?

[Pete Bessman]

++LASH.  

It is a real word, short and sweet, with a meaning that is relevant to
its purpose.  I rather like it.

[pb]