30 Jan
2003
30 Jan
'03
9:52 a.m.
I´m not a programmer, but If I were, I´d try to do
some
co-operation with
fruity-developers and do an linux-support to the fruityloops.
´cause it´s
only the question of time&money.
I don't think that they like to share the code with a developer
and why should anyone port Fruity Loops to Linux without
getting money, when Cakewalk sells his work later on?
It would be better to write an open-source program from scratch.
Regards,
J.Backhaus
30 Jan
30 Jan
5:53 p.m.
New subject: [linux-audio-dev] fruityloops on linux?
> I´m not a programmer, but If I were, I´d try to
do some
> co-operation with
> fruity-developers and do an linux-support to the fruityloops.
> ´cause it´s
> only the question of time&money.
I've tried - I offered to do it under NDA for free. They turned me down
because "It would be too hard to explain the code to someone". That says to
me that it is crappy code that the developer (one guy) does not want to
document.
It would be better to write an open-source program
from scratch.
Which is why I got into defining XAP. Help design XAP, then a good Fruity
clone on top of it.
7:01 p.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
On Thursday 30 January 2003 22.46, Tim Hockin wrote:
Crappy code should be *fixed*, not documented, BTW. ;-)
Yeah. And speaking of which, what's going on ATM?
As usual, I'm hacking furiously on Audiality, which is kind of related
as it's as close to a working prototype it gets right now (I'm even
tracking the latest fads in XAP control ramping ;-) - although it's
not *only* event system stuff I'm messing with. Must get ALSA 0.9
support working, and I've been playing with that new reverb, cleaning
up a little etc...
Anyway, I've been thinking about XAP and this Unified effort. A few
facts, assumptions and questions:
1) We don't have *any* serious instrument plugin API
on Linux, and we have waited long enough already.
2) Some of us have spent countless hours thinking about
this stuff, hacking similar things etc.
3) XAP is almost ready for alpha implementation, wheras
this new API is, AFAIK, 100% vaporware, if even that.
4) What is more likely to have effect on things?
a) Documents and comments from some mailing
list members who got themselves an MMA
membership.
b) A tested and working plugin API that's
used in real applications.
c) A tested and working plugin API that's
used in real applications, and is backed
by MMA members.
What I'm saying is basically that we have nothing to lose, and
possibly a lot to win.
The worst situation we can end up in if we go ahead with XAP is two
plugin APIs on Linux; XAP and a new, totally incompatible API. That's
still a lot better than the *current* situation on Windows and Mac
OS.
The alternative is to sit back and wait while people get tired of
waiting for Linux audio to mature, or some company throws a
proprietary API in the mix, and/or forces some old legacy crap from
Win32 or Mac OS upon our platform of choice.
Given the time frames we're talking about here, and that XAP is almost
in alpha (if that term applies to APIs), I don't really think there's
more than one sensible choice here. Most of the thinking is already
done, and we *need* that API, yesterday.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
> I´m not a
programmer, but If I were, I´d try to do some
> co-operation with
> fruity-developers and do an linux-support to the fruityloops.
> ´cause it´s
> only the question of time&money.
I've tried - I offered to do it under NDA for free. They turned me
down because "It would be too hard to explain the code to someone".
That says to me that it is crappy code that the developer (one
guy) does not want to document. It would be
better to write an open-source program from scratch.
Which is why I got into defining XAP. Help design XAP, then a good
Fruity clone on top of it.
9:51 p.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
down because
"It would be too hard to explain the code to someone".
That says to me that it is crappy code that the developer (one
guy) does not want to document.
Crappy code should be *fixed*, not documented, BTW. ;-) Which is why I
got into defining XAP. Help design XAP, then a good
Fruity clone on top of it.
Yeah. And speaking of which, what's going on ATM? Anyway, I've been thinking about XAP and this
Unified effort. A few
facts, assumptions and questions:
What I'm saying is basically that we have nothing
to lose, and
possibly a lot to win.
Agreed 100%.
Tim
31 Jan
31 Jan
9:41 a.m.
New subject: [linux-audio-dev] fruityloops on linux?
"Tim Hockin" <thockin(a)hockin.org> wrote:
it should be both fixed AND documented
That's an Open Source view though. I don't think fruityloops code can be
called crappy, because it works very well and the end product is much loved
by it's users. Maybe the code is messy and undocumented (I don't know, none
of us have seen it) but it is completely their decision if they want to
work like that. And if most of the information is in one guy's head (like
it is in most music software companies I think) at least that guy has
some job security!
Paul.
_____________________________
m a x i m | digital audio
http://mda-vst.com
_____________________________
down
because "It would be too hard to explain the code to someone".
That says to me that it is crappy code that the developer (one
guy) does not want to document.
Crappy code should be *fixed*, not documented, BTW. ;-) 
9:59 a.m.
New subject: [linux-audio-dev] fruityloops on linux?
And if most of the information is in one guy's head
(like
it is in most music software companies I think) at least that guy has
some job security!
Paul.
Well that is as long as he keeps his head :D heheh
or they come up with some kind of brain wave device that records everyone's
thoughts. Who knows maybe it exsists!
pawL
10:35 a.m.
New subject: [linux-audio-dev] [ZKM] Accomodation for LAD Meeting in Karlsruhe
Hello,
Frank and I decided to assist you in the choice of a hotel for the LAD
Meeting in Karlsruhe. The goal is to book only one or two hotels. This
way we might be able to negotiate a special offer (in March there is not
likely much else going on in Karlsruhe). Also it is probably much nicer if
you already meet colleagues when having breakfast in the hotel.
Frank has offered to check some hotels next week or so. If you would like
us to make a reservation for you, please send me email, including the
desired price range and the number of days you will stay.
In addition to that, a cheap lodging possibility has
been added to http://on1.zkm.de/zkm/stories/storyReader$3029
Matthias
--
Dr. Matthias Nagorni
SuSE GmbH
Deutschherrnstr. 15-19 phone: +49 911 74053375
D - 90429 Nuernberg fax : +49 911 74053483
11:37 a.m.
New subject: [linux-audio-dev] [ZKM] Accomodation for LAD Meeting in Karlsruhe
On Fri, Jan 31, 2003 at 03:28:28 +0100, Dr. Matthias Nagorni wrote:
Hello,
Frank and I decided to assist you in the choice of a hotel for the LAD
Meeting in Karlsruhe. The goal is to book only one or two hotels. This
way we might be able to negotiate a special offer (in March there is not
likely much else going on in Karlsruhe). Also it is probably much nicer if
you already meet colleagues when having breakfast in the hotel.
Frank has offered to check some hotels next week or so. If you would like
us to make a reservation for you, please send me email, including the
desired price range and the number of days you will stay.
Thanks,
I'm staying for four nights (Thurs 13th to Sun 16th), the prices all
looked OK.
- Steve
2:20 p.m.
New subject: [linux-audio-dev] fruityloops on linux?
Crappy code should be *fixed*, not documented, BTW.
;-)
it should be both fixed AND documented I don't think fruityloops code can be
called crappy, because it works very well and the end product is much loved
by it's users. Maybe the code is messy and undocumented (I don't know, none
of us have seen it) but it is completely their decision if they want to
Just because code is crap doesn't mean it can't run, or even run well.
work like that. And if most of the information is in
one guy's head (like
it is in most music software companies I think) at least that guy has
some job security!
It's inane, dangerous, and stupid for their management to LET HIM work like
that. The minute he gets pissed off, or hit by a truck, or comes down with
some awful disease (god forbid), they are S-C-R-E-W-E-D. Hell, if he takes
a vacation, development stops.
Their product is great, it gets more and more attention and users. Risks
like this are bad. At least, they are to my sensibilities. I'd never run a
company that way.
10:54 a.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
On Friday 31 January 2003 02.44, Tim Hockin wrote:
it should be both fixed AND documented
Well, yes. What I'm saying though, is that documentation is not a good
substitute for readable, structured code. Preferably, structure,
naming etc should make the code understandable without the need for
explaining everything in comments.
The problem with comments is that they all too often describe what you
*think* the code does, rather than what it's about...
I'm speccing. The mess of changes to the header were losing too
much detail, so I am writing the spec first :) Hopefully will have
a Table of Contents and draft this weekend.
Ok, sounds good.
I'm in the process of getting Audiality to work with Rosegarden, which
includes implementing ALSA sequencer support in Audiality, and doing
some work on Rosegarden's event list editor.
Next, I plan to switch to what I call "Unified Events" throughout.
These are events without explicit action codes, using cookies for the
*full* encoding of both action and target. I'll give the event
receiving units a minimal API to request cookies for controls and
actions, and then ditch the current mess that is action codes and
control indices. Control setting and ramping is done with a single
RAMP event.
I plan on using controls for *everything* as the basic design goal.
The START and STOP events (corresponding to note on and off) will be
replaced by a single "gate" control, and I *think* I'll implement
VVID attach/detach as a control that looks at the value to decide
what to do. I'm not happy with the idea that this control actually
messes with the VVID rather than a voice control value, but this
approach seems to have other advantages. Remains to see if they
outweigh this minor ugliness.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
down because "It would be too hard to explain the
code to
someone". That says to me that it is crappy code that the
developer (one guy) does not want to document.
Crappy code should be *fixed*, not documented, BTW. ;-) Which is why I got into defining XAP. Help design
XAP, then a
good Fruity clone on top of it.
Yeah. And speaking of which, what's going on ATM? 
30 Jan
30 Jan
11:15 p.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
4) What is more likely to have effect on things?
a) Documents and comments from some mailing
list members who got themselves an MMA
membership.
b) A tested and working plugin API that's
used in real applications.
c) A tested and working plugin API that's
used in real applications, and is backed
by MMA members.
d) talk to the people on the music-dsp list who actually write
plugins (in some cases making a living from it), and see
what they have come with over a year of discussing a new
plugin API.
nobody visible on this but steve harris and jesse chappel have ever
actually written any plugins for LADSPA. i would suggest that the
arrogance of designing a new plugin API without this experience is a
bit much. at least go check out what they have been up to.
--p
31 Jan
31 Jan
12:27 p.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
On Friday 31 January 2003 04.12, Paul Davis wrote:
Yes... Only I've never actually *seen* anything going on on in public
on the list. I've been on the list for at least 2.5 years, and during
that time, nearly all mentions of "plugin API" are in posts that I've
written myself. I must have been asking the wrong questions, because
no one on that list have ever shown much interest in plugin API
discussions.
I could have missed it, of course. I'll check the archive.
I did read the PTAF document BTW (which has not been mentioned on the
lis during the last 2.5 years), although I don't see any obvious
connection with music-dsp. Seems like the discussions took place off
the list, or on some other list. Will investigate.
4) What is
more likely to have effect on things?
a) Documents and comments from some mailing
list members who got themselves an MMA
membership.
b) A tested and working plugin API that's
used in real applications.
c) A tested and working plugin API that's
used in real applications, and is backed
by MMA members.
d) talk to the people on the music-dsp list who actually write
plugins (in some cases making a living from it), and see
what they have come with over a year of discussing a new
plugin API. nobody visible on this but steve harris and jesse
chappel have ever
actually written any plugins for LADSPA. i would suggest that the
arrogance of designing a new plugin API without this experience is
a bit much.
Yes, that's a good point. I don't have much hands-on experience with
official plugin APIs myself, so I have to admit most of my
"knowledge" in the field comes from programming in general (mostly
real time stuff), general audio programming, reading plugin code and
studying API specs.
at least go check out what they have been up to.
Yes, I'll give it another try.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
2:01 p.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
On Fri, Jan 31, 2003 at 05:20:30 +0100, David Olofson wrote:
No, I've been on the list for a similar ammount of time, and I've not seen
this discussion, I think Paul meant a different list.
- Steve
d) talk to
the people on the music-dsp list who actually write
plugins (in some cases making a living from it), and see
what they have come with over a year of discussing a new
plugin API.
Yes... Only I've never actually *seen* anything going on on in public
on the list. I've been on the list for at least 2.5 years, and during
that time, nearly all mentions of "plugin API" are in posts that I've
written myself. I must have been asking the wrong questions, because
no one on that list have ever shown much interest in plugin API
discussions.
I could have missed it, of course. I'll check the archive.
2:27 p.m.
New subject: [linux-audio-dev] The future of XAP? (was: fruityloops on linux?)
On Friday 31 January 2003 18.54, Steve Harris wrote:
[...]
Yes... Which one? Obviously, I'm interested in anything related to
plugin APIs, and I *have* been trying to find discussions on the
subject, but it's hard. People are either "amateurs" like ourselves,
and/or not seriously interested in discussing plugin APIs.
Oh, of course, there have been discussions on the VST list. I have
taken part in that to some extent, if nothing else, to get a better
idea of what VST developers want and need. However, it seems that
it's not the right place for anything like an open, unbiased
discussion. The list *is* about VST, after all, and I have a feeling
that Steinberg isn't very interested in anything they don't control.
VST 3 development seems to be *totally* closed, at the same time as
they're "open to suggestions"...
I'm not sure what to make of it, but to me, they appear to keep saying
one thing and doing another. And frankly, I wouldn't trust them even
if they said VST 3 was going to be an open/free standard, so I'm not
very interested in VST as such; only it's design and feature set -
and that's a well kept secret so far.
Anyway, I'm off to hunt mailing lists...
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
I could have
missed it, of course. I'll check the archive.
No, I've been on the list for a similar ammount of time, and I've
not seen this discussion, I think Paul meant a different list.
7995
days inactive
7996
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
8 participants
participants (8)
-
David Olofson -
Dr. Matthias Nagorni -
Joachim Backhaus -
Paul Davis -
Paul Kellett -
pawL -
Steve Harris -
Tim Hockin