On Jan 30, 2008 5:15 PM, Gordon JC Pearce <gordonjcp(a)gjcp.net> wrote:
> On Wednesday 30 January 2008 16:10:31 you wrote:
>
> > Would be so kind and write thorough analysis which would show the
> > *all* of my claims as untrue or unjustified? Please GO AHEAD.
>
> Just shut up and go away, please. Maybe you can come back and join the fun
> when you've actually read and understood the GPL.
>
Give me the facts that i don't understand the GPL.
Otherwise you shut up and let the others discuss it, the thread will
die if nobody is interested in replying.
It is marked as [OT] so you're free to filter it out if you don't like it.
Thank you.
Gesendet: Mi 30 Jan 2008 03:25:17 CET
Von: "pete shorthose"<zenadsl6252(a)zen.co.uk>
> i even said "virtually no one welcomes drobilla"
> when you joined #lad on freenode.
> it was TEH FUNNEZ!
Ah, so that what was funny. But nothing from Dave or me was funny.
So apparently you have humour, but we don't.
Now you are explaining your oh so clever argument again an again.
That's just sad. Just missed another good opportunity to stop this crap.
Is it so hard to accept that Dave and you have different opinions on the
term "open source", especially regarding its historical use?
I don't get why you think he _has_ to answer you in a straight way.
Are you the inquisation?
> running roughshod over any dissenting voices safe in the ken that your
> position in the community affords you special privilege.
Good thing you are guarding us from this berserker while being a saint!
> now, the reason i'm rather more uhm.. "energised" than usual is due to that
> lovely
> little chat on irc that we had in the interim. where you so generously
> implied that,
> whilst it's presumably ok for you to fill up the lists with views on the
> validity of
> software licenses, us low folk better shut the hell up and not bother you
> with their
> silly views else you'll up and leave the community.
This is a very mean misrepresentation of what was said there. It wasn't
just Dave and me who found your behaviour there very silly and overly
agressive.
> well you know, if you're that sensitive, don't discuss it in the first
> place.
Good thing you are not sensitive at all, but take it all with good humour.
> i'm probably as arrogant and aggressive as you but at least i try to keep
> it
> under wraps eh?
No, you don't, obviously.
Let's just assume you are right and Dave was wrong. Now what? Did this
whole endevour lead to anything good, any insight, change of mind?
I would ask to stop with this again, but I bet you have to have the last word ;p
--
Thorsten Wilms
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…
Hehe, succinctly put Christian.
Just doing a quick count of all the lines that have been written about this,
and the sometime belligerent enthusiasm attacking LS and questioning their
integrity because they're perceived as not being 'pure' by interpretation,
by some of you, and just since i've been here, there seems to be a lot of
code, sorry i mean text, written.
Makes me wonder just what the incentive is, to batter this to death over and
over again, instead of being admired for the quality and skill of coding
most of you have already proved you are capable of.
To offer a counterweight to this, have all you craftsmen considered getting
together in a concentrated team effort, free of politics, and indulge in an
intense push to expand Jack and Jackdmp (for example) to incorporate kernel
level audio, with modules, and do away with alsa altogether? Now that WOULD
be something to talk about, and a wonderful incentive for developers to come
together as one, with a common goal for the greater good. Jack is already
'king of the empire', in my humble opinion, and would expand it's grip on
the planet even further with this final step towards ONE complete linux
audio and midi solution.
I live in hope that you chaps will take a deep breath, and use those
obviously competent typing skills you're exercising at the moment, in
writing more excellent code that i can use, and continue to admire and
respect you for.
Alex.
On Jan 29, 2008 1:42 PM, Christian Schoenebeck <cuse(a)users.sourceforge.net>
wrote:
> Am Dienstag, 29. Januar 2008 06:25:31 schrieben Sie:
> > On Sat, 2008-01-26 at 03:16 +0000, Christian Schoenebeck wrote:
> > > So get it: there is NOT only one definition of the term "open source"
> > > when standing alone. Like with many unspecific short terms, different
> > > people have different opinions of those short terms.
> >
> > Yours just coincidentally is shared by virtually nobody and it just so
> > happens that this arbitrary definiton matches exactly your software
> > which you wish to call 'open source' for PR reasons.
>
> Right, just by the majority of e.g. all Windows and OS X users, hmm who
> reflect the majority of all users anyway. And right, I forgot I'm
> promoting a
> product. Thanks Dave for enlighten us about the truth! Now I clearly see
> there is only white and nothing else than white! Well, maybe black, but
> the
> black ones are evil by definition and don't count.
>
> Thanks my Pope! How could I ever have doubts in your holy inerrable words.
>
> CU
> Christian
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
Dave Phillips wrote:
> So responding with sarcasm, "We'll do it my way or not at all"
> conditions, and a confrontive attitude qualifies as "the spirit of
> collaboration" ? Geez, you guys are really winning me over.
It's the good right of Dave and Lars to not care or even outright
reject closed software. They could have said it more diplomatic
terms ... but now you make a drama of it.
It could even be that both never claimed to be open minded ;)
Dave puts an incredibly amount of effort into several open projects.
Why would he go out of his way to help adding capabilities to
closed software that kinda competes with what he works on?
Producers of closed software gotta love competition and doing it
all by themselves.
> No fear, no-one's going to ask you or DR for help in this matter.
There are very few others who could help in this matter, so what
do you think you gain with this confrontative behaviour?
Now you could say going to that forum and correcting
misconceptions regarding LV2 should be easy enough and
worth it, but even that eats time of which there is so little in a day.
Plus to me it sounds like that guy doesn't want to get it.
--
Thorsten Wilms
Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl.
http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…
Fons Adriaensen:
>
> On Fri, Jan 25, 2008 at 12:57:19PM -0500, Stephen Sinclair wrote:
>
>>>> Also, nice in the fact that you can do per-sample computations easily,
>>>
>>> How ? I seem to have missed something...
>>
>> Because you can wait in a 1-sample loop?
>>
>> Yes, it will use your whole CPU for a loop like that, but this thread
>> is about prototyping. Obviously you'd rewrite in C for a real
>> application.
>> I never claimed chuck is perfect, but I've been liking it a lot
>> lately. Sure, it can have performance issues depending on how you use
>> it, but the nice thing is having the option to abuse it that way when
>> necessary.
>
> This is one of the things I wanted to create a 'rapid prototype'
> for recently. I needed a jack client implementing:
>
> - a delay line,
> - allowing high-quality fractional-sample delays,
> - at least 12 outputs, for each two controls: delay, gain,
> - smooth 'crossfading' between two control sets, both delay
> and gain, controlled by a GUI or by OSC.
>
> It should not take more than 20% CPU on a 2G P4
> (other things have to run at the same time).
> If you know how to get this faster than by actually
> writing it in C++, please let me know !
>
Quick version for snd-rt below. It use about 10% on my
xp2800, but its easy to optimize so that it use a lot less
by making the dsp function call "out" and "in" only one
time. (that optimization requires two more lines of code,
but the version below is the straight forward one)
I'm not quite sure what you mean by "smooth 'crossfading'" though,
but at least the gain values are interpolated to avoid clicks
when changing values. I'm not sure if that was what you ment.
Guess its time to learn scheme now Fons? ;-)
Oh well, hopefully someone will find this interesting.
To run it, just paste the text below into the terminal snd-ls
was started from.
(define-rt-vector-struct das-delay
:delay (make-delay 20000)
:gain (make-glide-var 0 0.001))
(definstrument (mdelay num-delays)
(letrec* ((das-delays (map make-das-delay (iota num-delays)))
(instrument (<rt-play>
(lambda ()
(for-each (lambda (das-delay)
(out (* (read-glide-var (=> das-delay :gain))
(delay (=> das-delay :delay) (in)))))
das-delays))))
(exit (lambda ()
(-> instrument stop)
(-> d hide)))
(d (<dialog> "multi delay" exit
"Close" exit
"Stop" (<- instrument stop)
"Start" (<- instrument play))))
(for-each (lambda (n das-delay)
(set! (mus-length (=> das-delay :delay)) 1)
(<slider> d (<-> "gain " n) 0 0 2
(lambda (val)
(write-glide-var (=> das-delay :gain) val))
100)
(<slider> d (<-> "delay " n) 1 1 20000
(lambda (val)
(set! (mus-length (=> das-delay :delay)) val))
1))
(map number->string (iota num-delays))
das-delays)
(-> d show)))
(define mdel (mdelay))
Here's a list of all LASH suggestions expressed so far, as well as some new
ones. It's quite a bunch, and it goes without saying that this is NOT A PLAN;
no sane person would actually try to cram all of these into an application.
If my application gets chosen for Summercode I'll only be concentrating on a
few key things (to be announced later, maybe after another brainstorm).
So, please take this as a memo, and please do comment. The internet doesn't
contain enough ASCII yet.
Suggested changes to internal structure:
* Interact with JACK using the JACK D-Bus interface. Lashd no longer required
to be a libjack client.
- Jackdbus needs a port settings interface.
* Interact with LASH clients using D-Bus (change liblash's transport to use
D-Bus).
- What if the client has its own D-Bus event loop and wants to manually
handle the LASH protocol? We need an option to also allow this.
* Replace liblash's server interface with a LASH D-Bus interface. LASH control
applications no longer required to be liblash clients.
- Requires API change.
* Certificates and encryption for communication protocol.
- What the "communication protocol" refers to is another question...
* OSC (?)
* Server rewrite in C++.
* Client lib rewrite in GObject.
API change suggestions:
* Break it? How? When?
- Probably unavoidable eventually.
* Remove the server interface from liblash. Controlling LASH will happen
through a D-Bus interface.
- Dave Robillard has expressed that the current interface separation makes
it difficult to write a LASH control application which is at the same time a
LASH client (Patchage).
* Mandate that LASH clients shall not modify any external port connections.
- Actually enforce this using JACK ACL? (A partial solution, doesn't help
with ALSA and others.)
* Make the save directory "static" to clients unless a change notification is
sent.
* More generic patch system API.
* Use callbacks instead of current event framework.
* Add "test disk operation" function; the server can ask the client to test if
it can actually read from and write to the specified directory.
Feature addition suggestions:
* Lashd should capture clients' stdout and stderr and keep log(s) in the
project dir.
- One common log file or per-client ones?
* Preserve/restore JACK settings other than port connections.
- Make this optional; the user must be able to tell LASH to not touch any
JACK settings.
- Should this be the responsibility of a JACK controller app?
* Export/import session; create or unpack a tarball of the session directory.
* Light save functionality; clients can reference files outside the session
directory.
* Managing of non-LASH apps.
* Preserve clients' X11 properties, such as window position, screen,
workspace, etc.
* Ability to merge sessions.
* Support for multi-host sessions.
- Should the LASH<->client protocol support this directly (socket-based
connections), or
- should LASH daemons on different machines be able to connect with one
another (master session & slave sessions)?
* Save the client data in $client_dir under a sub-dir to prevent the client
from overwriting config files.
* Support for dictating client loading order, and which other clients need to
be loaded before a client can load.
- Alternative solution/scheme: client priorities.
* Track naming
* Guaranteed save directory availability
* Graded saves. (Different kinds of saves? How many different kinds?)
* Networked audio (audio/MIDI ports over network).
* User interface standard recommendation (documentation).
* Automatic client installation/in-built package manager.
Juuso
Frank Barknecht:
> > The second problem (besides its lack of interactivity) I have about faust
> > is that is purely functional. I have programmed lots of code in purely
> > functional style, and I like it very much, so thats not the issue. But, I
> > feel that being forced to work in one paradigm gives me less
> > possibilities.
>
> I think, Lua (with Vessel, see my other post) may be a good compromise
> of both worlds.
Vessel/Lua seems very nice, but it doesn't seem to offer sample by
sample processing. And even if it did, it would be terrible slow.
Faust or snd-rt are better options for doing those kind of tasks.
> (It may have not enough parenthesis for your taste. ;)
>
Yeah. :-)
It amazes me, though, that people use s-expression as an argument
against languages. Even people with phd in computer science seems
to think that s-expression is a valid argument against using a
language. If they have spent 30 years of programming, how hard
can it be then to use a couple of weeks getting used to s-expressions?
Doesn't make sense to me.
> Actually as I recently had a quick look at Rick Taube's SAL language
> syntax for working with Common Music, I was amazed at how similar SAL
> looks and feels to straight Lua code. I even wondered, if inventing a
> new domain specifc language like SAL was necessary.
I didn't know SAL was a domain specific language? I thought SAL was
just a synactical frontend for scheme and common lisp?
On Jan 27, 2008 10:44 PM, Daniel Schmitt
<myloginislongerthanyours(a)gmail.com> wrote:
>
> On Jan 27, 2008 9:59 PM, Marek <mlf.conv(a)gmail.com> wrote:
>
>
>
> >
> >
> >
> > But let's have a look at these statements from the 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..."
> >
> > 1. Basically "You may charge a fee for the physical act of transferring a copy..." translates to "You may *only* charge a fee for the physical act of transferring a copy..." as the GPL doesn't state that you may charge for the computer program or any other services related to it other than distribution and providing warranty. Otherwise such statement made by the GPL would be *invalid*.
>
>
> This interpretation is at odds with the FSF's own interpretation. Check http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesTheGPLAllowMoney to get it directly from the gnu's mouth, so to speak.
Show me one example in GPLv2 which would tell me that i can charge for
*a copy*, not for *distributing a copy*(!).
The FSF clearly uses wrong wording (see my FedEx example) because they
are always talking about encouraging *distribution*
http://www.gnu.org/philosophy/selling.html:
Quote:
"--> Selling <-- Free Software
Many people believe that the spirit of the GNU project is that you
should not charge *money for distributing copies* of software, or that
you should charge as little as possible — just enough to cover the
cost.
Actually we encourage people who *redistribute free software* to
charge as much as they wish or can. If this seems surprising to you,
please read on."
Please note : Selling software != Distributing for charge and there
are *many* ways to sell software (even while not distributing it at
all).
>
>
>
>
> As for the original topic: under the GPLv2, anyone can build hardware around a piece of GPLed software as long as they offer to give the full source, including any modifications they made, to anyone asking for it, at cost.
Nope. If the software represents a substantial part of the hw based
product, you are not charging for distribution of the software, you
are charging for the entire *product * which would be useless without
the software. If there are software *alternatives* that are easily
installable on your hardware and you chose to prefer one of them, then
you're only distributing the sw along with the hw you are selling.
>
>
>
>
> The restrictions desired by the LS crew therefore do require additional terms beyond the GPL, and the resulting license is not compatible with the GPL. These are undisputed facts.
Undisputed facts? :) Search for "we believe" in ->
http://www.fsf.org/licensing/licenses/gpl-faq.html
>
>
> The one mildly interesting question is whether this state of affairs makes LS non-free; reinterpreting a license it doesn't even use is not going to clarify that.
It's free for users to study, modify the code and run the code for
any purpose, to distribute it to others, whether modified or not.
And see the coincidence, these rules apply to LinuxSampler whether
with or without exception.
GPL is not public domain, it's not charity for midsize or big companies.
In general, the GPL enforces third parties to *give back*. If you
can't give back code, you can give back money(the only exception
being, you're encouraged to distribute, for that sake you can earn a
few bucks if you're able to).
Marek
On Jan 27, 2008 9:59 PM, Marek <mlf.conv(a)gmail.com> wrote:
>
> But let's have a look at these statements from the 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..."
>
> 1. Basically "You may charge a fee for the physical act of transferring a
> copy..." translates to "You may *only* charge a fee for the physical act of
> transferring a copy..." as the GPL doesn't state that you may charge for
> the computer program or any other services related to it other than
> distribution and providing warranty. Otherwise such statement made by the
> GPL would be *invalid*.
>
This interpretation is at odds with the FSF's own interpretation. Check
http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesTheGPLAllowMoney to
get it directly from the gnu's mouth, so to speak.
As for the original topic: under the GPLv2, anyone can build hardware around
a piece of GPLed software as long as they offer to give the full source,
including any modifications they made, to anyone asking for it, at cost.
Under the GPLv3 the same thing holds, with the additional stipulation that
if the hardware is field-upgradeable, anyone must be able to do it (e.g. if
the device checks for a cryptographic signature before executing the code,
the seller must provide the required key along with the source).
The restrictions desired by the LS crew therefore do require additional
terms beyond the GPL, and the resulting license is not compatible with the
GPL. These are undisputed facts. The one mildly interesting question is
whether this state of affairs makes LS non-free; reinterpreting a license it
doesn't even use is not going to clarify that.
Daniel.