On Friday 07 August 2009 20:10:14 you wrote:
> On Fri, Aug 7, 2009 at 5:34 PM, Raymond Martin <laseray(a)gmail.com> wrote:
> > Not at all. There is even evidence in the FSF documentation somewhere
> > exactly
> > about this point and they vehemently disagree with any attitude like
> > that. We
> > all know very well the situation of Emacs, Xemacs, and various other
> > forks.
>
> The FSF is not the law. I suggest you look up Trademark Law to realize why
> you are wrong, and why you are subject to a lawsuit for knowingly creating
> a product that is infringing on an already existing trademark(Regeristered
> or Unregeristered would make a small, but only small, difference in this
> case), and can easily be confused as such. In fact the case against
> forcing you to change it is rather strong because not only is your product
> nearly identical in name, it is nearly identical in function and can be
> easily confused with the original.
Another fool. Trademarks apply to commercial interests, the program is
non-commercial in nature. Thus it would be very difficult for anything
to be done about this for creating a free program from a free program.
Maybe you should check the fact that there is already another program called
improvisor that exists that is not Impro-Visor, it is a commercial company
that could claim trademark infringement against Impro-Visor.
So if anybody is in a problem it will be Impro-Visor first.
Raymond
I'm not a developer, just interested in Linux audio development
because I use Linux audio software almost daily, and as such I've been
lurking on this list for awhile. So this is just a practical
suggestion / brainstorming idea, not meant to incur flames (I wish I
could heat my studio by the flames this list generates). One
complaint I've seen raised a number of times is that in the world of
Linux, especially the audio realm, there are too many choices and not
enough decisions made. In the wider scope, The Linux Foundation is
trying to address this by maintaining a standards base to help promote
open standards across mainstream distros... So here's the idea: why
not make one of the responsibilities of the Linux Audio Consortium be
establishing and maintaining a standards base? As far as I can tell
from http://linuxaudio.org/about , it's not currently one of the
Consortium's roles. I.e., there could be a formal document that says
in a nutshell, "If you want your Linux audio application to integrate
seamlessly on most audio-centric distros, here's what it should
support. And, if you want your pro-audio-centric distro to be
seamlessly compatible with all these great apps, here's what it should
include and how it should work." Of course it would be a voluntary
standards base, and every developer / distro team can still do
whatever they like, so that innovation can continue... but as
protocols/interfaces/frameworks/whatever are developed and show their
merit, they can be included in the standards base, and
old/deprecated/redundant things removed, so that people aren't wasting
their time supporting old code. So to sum it up, *someone* needs to
make some tough decisions, or Linux audio will continue to stagnate...
why not the Consortium? It's the only real Linux audio "authority" or
central point of contact that I know of.
I'm sure there are many reasons this is a silly idea -- lack of time,
disagreements on what should be standardized, etc. -- but as I said
it's just an idea. I'd love some constructive criticism, even if it
just leads to a completely different idea getting implemented. By the
way, I apologize that this is basically just another "here's my idea
about what everyone else should do" kind of e-mails. I could maintain
a website and/or provide free hosting for the standards document(s),
if need be.
-Sean Corbett
blacktownsound.com (<- pardon the shameless spam)
On Sat, Aug 8, 2009 at 5:22 AM, James Cameron<quozl(a)us.netrek.org> wrote:
> On Fri, Aug 07, 2009 at 07:44:46PM -0600, Thomas Vecchione wrote:
>> You misunderstood what he was saying. Â The GCC compiler IS included on
>> the installation disks as part of the XCode program. Â You can also
>> download this program off of the internet(The download is over a gig
>> by the way last I looked). Â The complaint is that Apple only bundles
>> gcc with the XCode program and a lot of useless stuff that aren't
>> necessarily used by people like us. Â But they are used by most Mac
>> developers, and Apple I am sure wants to encourage their use and
>> 'their' way of doing things.
>
> Ah, I see, thanks. Â Yes, an encouragement. Â I get the point. Â An open
> ecosystem doesn't need to offer the same encouragement.
Yeah, that was my point. I checked my Debian testing gcc first and
verified that the download is far less than 1 MB.
I believe the latest XCode is over a gig, but my experience wasn't
quite so bad; it was an older ibook, discs long gone, but using an
outdated version that was only 300 some MB, still too much, and
significant given the speed of the comp.
Maybe here's a task for some beneficent soul like me, to compile some
GCC tools on OSX and offer small downloads.
-Chuckk
--
http://www.badmuthahubbard.com
On Fri, Aug 7, 2009 at 7:21 PM, James Cameron <quozl(a)us.netrek.org> wrote:
>
> The installation discs for Mac OS X already contain software licensed
> under the GNU GPL (e.g. bash), so the additional obligations under the
> GPL would not have been the reason to exclude a compiler.
>
> It seems much more likely that it was the size. Several hundred
> megabytes that aren't required by most users should always be omitted
> from the installation discs, so that more room is made for what most
> users require.
>
> The same is done with Ubuntu and Debian installation images. Most of
> the tools needed to build Ubuntu are not included in the installation
> image, and require downloading "apt-get build-dep $packagename".
>
You misunderstood what he was saying. The GCC compiler IS included on the
installation disks as part of the XCode program. You can also download this
program off of the internet(The download is over a gig by the way last I
looked). The complaint is that Apple only bundles gcc with the XCode
program and a lot of useless stuff that aren't necessarily used by people
like us. But they are used by most Mac developers, and Apple I am sure
wants to encourage their use and 'their' way of doing things.
Seablade
David Robillard:
>> Let's just fix the interaction between pulse and jack and be done with
>> it.
>
> That is one solution.
>
>> It's harmful to suggest that it things are less than they are
>
> Read the user posts in this thread, or ths post that started it. Things
> are as they are. Pretending everything is fantastic when it's not
> doesn't help either.
>
Well, in my opinion, everything really is fantastic right now.
Pulseaudio interacts perfectly with jack, pulseaudio doesn't screw
up jack in any way (as far as I can remember observing), and
all programs using jack, alsa or pulseaudio make sound, simultaneously,
without any notable latencies issues with alsa programs. Maybe
I was lucky, and I'm probably not a newbie either, but at least
I'm not _pretending_ everything is fantastic: it really is.
A person coming directly from win/mac probably wouldn't have
succeeded though, since jack needed to be configured and
I had to manually install the pulseaudio jack sink, edit
various files in /etc/, plus perhaps doing other stuff
I don't remember anymore.
standard ianal disclaimer applies.
at the risk of starting another zillion-mail thread, here's how i
understand the gpl to work under german laws (which should be almost the
same in most other countries):
a) there is a difference between the license and the copyright. what
many people fail to grasp is that the original copyright holder (if it's
actually a single person or closed group) is not bound by the license -
s/he can choose to distribute the product under any terms s/he sees fit.
the license applies only to people re-distributing the product.
so it does not make sense to accuse an original author of not providing
makefiles, scripts etc, for original code. specifically so in the light
of the famous "AS-IS", "WITHOUT FITNESS FOR ANY PARTICULAR PURPOSE"
paragraph.
ripping out makefiles from re-distributed code is another issue.
b) there is a difference between license and evangelist lingo and the
actual *contract* that is agreed upon by licensor and licensee.
the GPL cannot be viral in the sense that any code that incorporates GPL
automatically becomes GPL as well.
what happens instead is this:
* you use GPL code in your product so as to make your product a "derived
work".
* by including the GPL code, you are accepting the GPL (as stated in the
license). the original author has issued a standing offer for a contract
(the GPL), and your use of the code indicates your acceptance. thus, a
contract is formed between the original author of that code and yourself
(through "konkludentes handeln" or "implied agreement by action" in
german legalese, no signing of papers or verbal exchange needed here).
* you fail to comply with the GPL by not releasing your product under
the same terms.
* this means you are violating the license of the included GPL code and
are re-distributing the included GPL code without permission.
so this is a *breach of contract*, and anything that follows is about
the original author's copyright, not your own, or how you license your code.
you are now liable to a copyright infringement suit, a cease and desist
and possible damages.
from this point on, there are two ways to remedy the situation:
* you can stick to the original contract and comply with the GPL in the
future. since this happens to mean your code has to become GPL as well,
it is what causes the myth of the "viral" GPL.
* you can rip out the GPL code and continue to use your old licensing
terms (after you have settled the infringement suit).
all this means that if somebody uses GPL'd code without releasing under
GPL him/herself, s/he is in breach of contract with the original
author(s). it *does* *not* *mean* that you can now assume the entire
package is up for grabs under the terms of the GPL.
best,
jörn
Hi,
For those of you who are not subscribed to LAU, yesterday I had time to
run a test to see how easy and stable it was to run pulseaudio with jack
on Fedora 11.
I had a few problems at first but after upgrading to pulseaudio-0.9.16
(latest dev version) I was able to successfully connect Pulseaudio to
Jack and play tracks with Totem. It was still a little unstable as I was
able to bring pulse down a few times while using the
gnome-volume-control applet. However jack was not affected by pulse dying.
I did this on a standard Fedora kernel with a 2 core intel and 4 GB RAM.
My system load without any audio playing it was around 10%. While
playing a track with Totem through PA into Jack was around 20%. This
could be due to the visuals that were running at the same time. I was
able to listen to a complete 30 minute dj mix without any dropouts while
still using my system as usual. I am going to run a full day test of
audio playback today.
I hope that this has conclusively proven that pulseaudio and jack can
exist together and that we are very close to having a complete desktop
solution.
I don't think any distros are currently shipping pulseaudio-0.9.16 but
they will in the next release cycle.
IMO all that is needed to complete the system is a sane default
configuration which we can all agree on and officially recommend to the
packagers.
- We have now have a couple of scripts on the net that can be used to
load module-null-sink/source to PA, starts jack and then load
module-jack-sink/source to PA. These can be added to qjackctl easily but
not system wide as several video apps have hooks to load jack if it is
not already running. I am doing this now as it is the quickest solution.
- The dbus method for jack2 is also useful if it can be given the above
logic instead of or aswell as the current which is to disable PA while
jack is running.
- Another option is that PA listens for jack and handles the sink/source
loading internally and automatically.
- The final option I can see is a seperate app that can replace jackd,
that loads the null sink/source, starts the real jackd and then loads
the jack-sink/source. It would also have to take care of the reverse
when jack is stopped.
I think it would be good if we can get some consensus on the officially
endorsed approach.
Cheers.
--
Patrick Shirkey
Boost Hardware Ltd
hi guys!
lwn.net has a very nice article on the progress of -rt in the latest .31
kernel:
http://lwn.net/SubscriberLink/345076/aab59b866d6f169d/
(this is otherwise subscribers-only coverage, brought to you by the
"free link" feature - if you have some bucks to spare, check out lwn and
consider subscribing, their s/n is quite exceptional.)
best,
jörn
On Thu, Aug 6, 2009 at 2:23 PM, drew Roberts<zotz(a)100jamz.com> wrote:
> On Thursday 06 August 2009 03:51:30 you wrote:
>> The second question becomes broadly irrelevant here if  we are
>> prepared to accept Bob did convey his intention that the Impro-Visor
>> code be GPL'd, but Arnout and I were responding to the blanket "use of
>> GPL code makes it GPL" (which would imply the second question above).
>
> And this I certainly agree with. Use of GPL code does not automatically make
> another program GPL. It just gives the author of that code a legal headache
> if the new program is not GPL.
Yes, exactly.
Chris
Hi Alex :)
I'll take the next bus and will reply to this mail only because of the
68000 issue.
alex stone wrote:
> [snip]
> I owned several variations of boxes including
> an Amiga (best midi timing on the planet), and my much cherished but
> now dead Fairlight.
>
I started with the C64 and then used the Atari ST (not STe, not TT
etc.). I don't know the Amiga, but the Fairlight.
Amiga, Atari ST and Fairlight are based on the 68000.
As I've written before, I won't argue for an OSS, I don't use privately
and I've explained that there are cracks that do, what I've said. I
stopped replying to this topic.
The C64 and Atari ST don't have any noticeable jitter, I still have
those computers, but reasons not to use them any more.
Linux with my machine is a PITA for usage with external MIDI equipment.
I don't know if this is fine for Windows on my machine, in January I
installed Windows and some audio software, but until now I didn't test
if I do have jitter with Windows too, I only tried to fix it for my
Linux installs.
But I was writing because of the averaged user, not because of my
trouble. 64 Studio is the only good working alternative I know, other
audio distros don't take care about special problems, e.g. that some
systems will disconnect clients when using JACK1, for 64 Studio JACK2 is
default.
I'm able to configure my Suse etc. for rt-audio, an averaged user isn't
able to do this.
Maybe to be continued, better if not and I'm half off-line now ;).
Ralf
