Jonatan Liljedahl:
>>
>>
>> Thanks for clearing up. But I'm pretty sure your idea is too
>> simple. We also need a way to create ports which are not
>> autoconnected.
>>
>> The ideal way, if we follow this thread of thinking, would
>> be to add another type of jack_port_register function, which
>> does not autoconnect:
>>
>> jack_port_register_no_autoconnect(client,...);
>>
>> However, this new API will break a lot of current programs
>> which are using the old jack_port_register function instead.
>> Infact I don't think there is any (sane) way to make your
>> proposal work without creating lots of mess with ports
>> in old programs who are autoconnecting when it shouldn't.
>
> I think my proposal with a JackPortAutoConnect bit in JackPortFlags is
> sane, it would not break old applications; they would continue to
> function exactly as they are now. but updated code can get rid of their
> own autoconnection and use this autoconnect bit in the flags to
> jack_port_register() instead.
>
Yes, as long as JackPortAutoConnect is false by default, that's
definietely a sane solution. Its basically the same kind of
proposal I made, just using a flag to jack_port_register
instead of a new function.
But there is one problem with it:
jack_client_t *client=...
jack_port_t
*out_port[0]=jack_port_register(client,...JackPortAutoConnect);
jack_port_t
*out_port[1]=jack_port_register(client,...JackPortAutoConnect);
<something happens>
jack_port_t
*new_out_port[0]=jack_port_register(client,...JackPortAutoConnect);
jack_port_t
*new_out_port[1]=jack_port_register(client,...JackPortAutoConnect);
The problem is that new_out_port[0] and new_out_port[1] will
connect to physical port number 2 and 3 instead of 0 and 1.
How do you fix this problem without adding a new function to jacklib?
Is there any reason why raw ALSA MIDI streams would stop
working if the process that opened them switches to
daemon mode ? (see mand daemon(3))
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
nick, thanks for your reply - i guess you intended it to go to the list
as well?
anyway, in case anyone else is interested,
Nick Bailey wrote:
> http://www.jcraft.com/jorbis/ any use?
cool, thanks! it's not java ME, but SE, but i may be able to steal code
from it.
best,
jörn
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
Fons Adriaensen:
>
>> On Tue, 2008-01-29 at 23:36 +0100, Yann Orlarey wrote:
>>
>>> A fully functional jack application can be easily generated using the
>>> faust2jack command or by pasting the above code in the online faust
>>> compiler (http://faust.grame.fr). The performances on my Vaio laptop
>>> (Intel Core 2 CPU T7400 @ 2.16GHz) is approximately of 2%.
>>
>> I think they call that "game, set and match".
>
> Not really, but still I'm impressed :-)
>
> - Even fdelay4 is not up to the task. There are
> gain variations of more than 6dB for a 20 kHz
> signal, Fs = 48 kHz. Even stranger, they are
> not symmetric w.r.t. the fraction of the delay,
> e.g. 10.3 samples shows a different gain than
> 9.7. Which makes me suspicious.
>
> - My usual grunge: unless you want me accidentally
> destroy some very expensive equipment which is not
> even mine, the generated JACK apps
>
> MUST NOT AUTOCONNECT --- NEVER --- TO ANYTHING.
>
We discussed this two years ago. I both respect and understand
your reasons to take your position on this issue, but I still
strongly disagree with you, and I also think its a bit sad
that you use such strong wording about an issue which there
clearly are two different views upon. Its also sad if you
destroy your equipment, but you are actually
yourself to blame if it happens.
And just to repeat my position: Unless someone can make
it probable that most people prefer jack applications not
to autoconnect by default, all jack programs should
autoconnect by default.
Anyway, this is a jack-dev issue, and there are various
ways to fix the jack server so that it will be possible
to turn off autoconnect [1] for those who prefer so.
However, you (the non-autoconnect people) must push this new
API or functionality into jack, because the rest of us are
satisfied with the current situation where almost all jack
clients autoconnect by default, and therefore its unlikely
for us to find the motivation to push this.
[1] One simple hack you can do is simply just to create some
new dummy ports and set those as being the system default
instead of the real system default.
That hack shouldn't take more than a few hours to
implement. If you feel so strongly about this issue,
you should make such a modification to jack.
Note, this is just a hack to fix the problem temorarily,
not a long-term solution.
As a complete aside to the gaiety and good natured frollocking going in the
GPL discussion, I'm writing to say thanks to Stephane and the Jackdmp team.
I've installed the latest incarnation (0.69), and it works a treat. The
system's never run so well.
Thanks fellas, your skill and determination is appreciated.
Alex Stone.
Darren Landrum:
>
> Okay, I'll see if I can make up for my awful post from before with a
> constructive question.
>
> If you wanted to quickly prototype an idea for a DSP routine, how would
> you go about it? It would need to work in real-time, but it wouldn't
> really need to be super-efficient for testing ideas.
>
> Thank you for the help.
>
For quick and interactive, imperative or functional,
realtime or non-realtime, development of dsp routines,
clm is your choice:
http://ccrma.stanford.edu/software/clm/
and in realtime:
http://www.notam02.no/arkiv/doc/snd-rt/
Lots of example code:
http://snd.cvs.sourceforge.net/snd/cvs-snd/clm-ins.scm?view=loghttp://snd.cvs.sourceforge.net/snd/cvs-snd/animals.scm?view=loghttp://snd.cvs.sourceforge.net/snd/cvs-snd/dsp.scm?view=log
+ many other files.
If you don't need tight feedback loops (As Albert calls it),
you might want to look at pd, csound, supercollider, etc. instead.
If you _really_ like functional programming and aren't
afraid to learn a really different syntax, faust might probably
be a very good alternative. I don't think you'll get the kind of tight
interactive development environment with it as the other systems
though. ie. you have to write code, compile up, run test, etc.,
while in the other systems, you can just write code and test directly.
Fons Adriaensen:
> Well, for the record, I am a professional user in every sense
> of the word you could imagine. I'm being paid to design and
> develop audio systems running on Linux, and that is my main
> source of income.
>
> If it works, and if it doesn't make a mess of the calibrated
> gains for each channel, and if you can convince the users of
> this system that they need it, you will be paid very well and
> then you can consider yourself a professional.
You can be as much of a professional user as you want to.
It doesn't change the fact that other professionals might
not want the system to behave like you do.
>A simple environment variable tested by
>all apps will do (e.g. something similar to 'EDITOR' which
>is used by most apps that need to start a text editor).
>
>Any app that directly connects to the sound card, without
>even offering the option not to do so, is like a musician
>walking into a studio and plugging his synth directly in
>the the control room's power amps. Even if he promises not
>to do that again next time, there's a good chance he won't
>be welcome anymore.
We agree about this. Snd has the environment variable
SND_AUTOCONNECT_PORT, or something, but a common name for
all programs would be much better.
On Tue, 29 Jan 2008 15:13:02 -0500
Dave Robillard <dave(a)drobilla.net> wrote:
> On Tue, 2008-01-29 at 19:28 +0000, pete
> shorthose wrote:
> > On Tue, 29 Jan 2008 13:44:46 -0500
> > Dave Robillard <dave(a)drobilla.net> wrote:
> >
> > > On Tue, 2008-01-29 at 18:22 +0000, pete
> > > shorthose wrote:
> > > > On Tue, 29 Jan 2008 11:41:39 -0500
> > > > Dave Robillard <dave(a)drobilla.net> wrote:
> > > >
> > > > > On Tue, 2008-01-29 at 14:00 +0000, pete
> > > > > shorthose wrote:
> > > > > > virtually nobody cares what you think.
> > > > > > how's that?
> > > > >
> > > > > Virtually nobody even knows who you
> > > > > are, let alone what you think. How's
> > > > > that?
> > > >
> > > > i'd agree with that entirely. i'm not very
> > > > active on this list nor in the community
> > > > in general. it's even truer in the wider
> > > > context. so, pejorative implications
> > > > aside, yeah, that's also a fair statement
> > > > to make. quite what it has to do with the
> > > > matter at hand, i'm not so sure.
> > >
> > > You started it, don't complain when you get
> > > what's coming ;)
> >
> > ok. get back to me when you can justify your
> > statement with something other then an ad
> > hominem.
>
> Um...
>
> You say X to me.
> I say X to you.
hardly. even if you missed the point (which i
doubt, having sparred with you on irc numerous
times, to altogether more humorous effect) i even
explained on irc that it was not intended as an
insult, that i was illustrating an invalid
debating tactic by using it against you.
in order to tackle it directly you cannot avoid
undermining your own use of it. and you knew it
too. hence you changed the subject to how i was
a nobody and hence irrelevant.
now, in the scheme of things, that may even be
true, but it doesn't make me wrong.
so there, that's cleared that up. _again_.
> You accuse me of ad hominem.
indeed. you didn't tackle my point directly,
preferring instead to question my right to
criticise you at all for reasons unrelated to the
topic of discussion. text book ad hominem.
i doubt that even you would attempt to dispute
that. (well, perhaps doubt is too strong a word)
> I'll get back to you when you know something
> about discourse other than being able to quote
> fancy words you don't seem to understand.
you just served up some fresh insults and still
didn't justify what you said. i tell you, i'm
not in the least bit fucking surprised.
now, if you feel the need, concoct some juicy
combination of pejoratives and craft them into
a rejoinder. it's a free shot at the basket
because i'm well and truly done talking to you.
i might as well be debating an ATM.
cheers,
pete.
Hi,
I'd like to clarify a few questions regarding GPL and LinuxSampler.
The GPL implicitly prohibits third parties from selling a computer program
licensed under the terms of GPL, by only allowing the following, quoting
GPL:
"...if you distribute copies of such a program, whether gratis or for a
fee..."
"... You may charge a fee for the physical act of transferring a copy..."
"You must cause any work that you distribute or publish, that in whole or in
part contains or is derived from the Program or any part thereof, to be
licensed as a whole at no charge to all third parties under the terms of
this License."
Basically:
1. selling a computer program licensed under the terms of GPL and
2. charging a fee for distribution of a computer program licensed under the
terms of GPL / charging for a physical act of transferring a copy
are 2 entirely different things.
When you sell a computer program you are charging for the costs(human
resources - developers, designers; technical resources - computers etc) you
have put into *developing a computer program* plus you are charging an
adittional fee based on your estimation of value that your product would
have on the market(offer/demand stuff)
When you distribute a computer program or charge a fee for physical act of
transferring a copy you are charging for the costs you have put into
*distribution of a computer program* plus you are charging an additional fee
based on your estimation of value that your *distribution service* would
have on the market.
This means that:
1. usage of a computer program licensed under the terms of GPL in a hardware
product, whether modified or not, is not a distribution of a computer
program licensed under the terms of GPL, and is thus prohibited by GPL.
2. usage of a computer program licensed under the terms of GPL, whether
modified or not, in a software product, the intention of which is not to
distribute a computer program licensed under the terms of GPL, is not a
distribution of a computer program licensed under the terms of GPL, and is
thus prohibited by GPL.
No.1 of course has an exception, you would have to sell a computer that has
a computer program licensed under the terms of GPL installed on it as a part
of distribution, for the purpose of selling the computer(for example with
preinstalled Linux distribution)
No.2 has several scenarios:
a) a distribution is an obvious case where a given computer program licensed
under the terms of GPL is a part of a bigger software product, the sole
purpose of which is to distribute, thus a distribution is fully GPL
compliant whether made available for transfer at no charge, or selled as a
package in stores.
b) a scenario where computer program must not be modified in order to become
part of another comuter program "...thus forming a work based on the
Program..." This means that if a computer program as a whole, whether
modified or not, becomes part of another computer program at *source-code*
level, then the terms of GPL apply to such derived work.
You can derive a work from another at source code level(by modifying the
original, by adding code to it while not modifying the original, or both)
but you can also derive a work at binary level. And if fact, the GPL doesn't
differentiate between source-code and binary level derived works:
"...any work that you distribute or publish, that in whole or in part
contains or is derived from the Program or any part thereof..."
So suppose a software developer goes on developing a cool GUI for a computer
program licensed under the terms of GPL which he intends to sell.
The GUI talks to the GPLed computer program via some kind of IPC.
He can claim that he's charging for his own program and distributing the
GPLed computer program along with it, since the two are in fact 2 separate
applications that communicate through IPC.
This might be true, but consider the following - the GPLed computer program
is capable of functioning as a standalone application, whereas the GUI
application is practically useless without the GPLed computer program, ans
is thus a derived work at *binary-level*.
The GPL states, that "...in whole or in part contains or is derived from the
Program...", which means, whether at source code level or binary level.
This has the following consequences:
A proprietary computer program that is not capable of functioning as a
standalone computer program, and is communicating with a computer program
licensed under the terms of GPL, in order to ensure its purpose and proper
functioning, is a derived work under the terms of GPL, thus the terms of GPL
apply to such work, and a software developer of such proprietary computer
program is *also* violating the terms of GPL by not distributing the
computer program licensed under the terms of GPL for the sole purpose of
distributing it.
So to summarize that with respect to LinuxSampler, the exception
"LinuxSampler is licensed under the GNU GPL with the exception that USAGE of
the source code, libraries and applications FOR COMMERCIAL HARDWARE OR
SOFTWARE PRODUCTS IS NOT ALLOWED" is in fact no exception at all, and is
already covered by GPL.
If someone finds such interpretation too vague for his own taste, he can
simply make an amendment to the GPL license, stating that you can only
charge for distribution of Program for the sole purpose of distributing it,
but not for the actual Program, which would basically equal to the above
mentioned exception.
Also note that this only applies to *third parties*, not the actual
copyright holder. He can issue another license if someone finds GPL too
restrictive for his needs, and charge for it.
So LinuxSampler is basically a pure GPLed computer program.
Marek