Hello again!
>
> Yes absolutely, I didn't mean to suggest that Ge or anyone else has
> broken the terms of GPL code. In fact I'm sure he wouldn't have done
> such a thing, and should have asserted that earlier, sorry.
>
>
Oh, good, I was a bit worried about that.
> I am pointing out that if someone came along who wanted to contribute
> to ChucK with GPL patches, then Ge would be put in a difficult
> position. He'd have to maintain this firewall between free software
> and iphone apps. As you say, the person with the patch could fork the
> code, but that doesn't make for a healthy free software ecology in my
> opinion. Every time you fork a code base, you double the effort...
>
>
Ok, then I agree, but that's Ge's problem. I assume that he knew from the
start that this could become a problem and that it may mean work. In the
post I quoted Ge mentions moving developments from ChiP to ChucK and doesn't
mention going the other way around so I assume he thought of this already.
It would be hard for him if you'd submit a patch that would -say- make the
internal sound engine of ChucK run 10 times as fast. As I see it that's Ge's
problem, not ChucK's and if all is right Smule is making some money for Ge
which will hopefully offset the work it all involves.
If, as with rjlib, they don't have an internal fork for each license,
> then it would be legally impossible to get GPL patches in.
>
>
I assume there was a fork. There would have to be since ChucK runs on
desktop OS's which the iPhone is not, the hardware is quite different and
Smule's instrument/toy products are only similar to ChucK in that both make
sounds. You'd have to be quite silly to put all features new to ChucK into
Smule products because new ChucK features tend to crash or misbehave until
we have caught all the bugs. That's ok for experimental audio systems, not
so ok, if it means risking half a million people who want their dollar back.
While I see your point about forks being "unhealthy" not forking here would
be downright deadly (to Smule).
> Ok to clarify. I define a healthy free software community as a
> codebase with a maintainer able to accept patches based on merit and
> redistribute it as a nice codebase, all under the same free software
> license. As it is, if I give Ge a super duper GPLd patch (unlikely,
> because my code is scrappy as hell), I assume he'd be reluctant to
> take it, because he wouldn't be able to use it with the rest of ChucK
> on the iphone.
Ok, yes, that would be a issue if that situation would arise. In that case
the patch could be rejected (bad) or it could be put into plain ChucK or it
could be put into both ChucK and ChiP, assuming you could strike a deal with
Ge over it's usage. Another scenario would be opening the audio core of ChiP
which would be the bit that would be shared with ChucK.
That could mean a port of your code to hardware you don't own, but that
could already happen. I could -theoretically- port your code to run on my
Atari, release that source and you still wouldn't have a Atari.
There are questions here, I agree, but it's going too far for my tastes to
now call ChucK "non-free".
> Perhaps it makes it clearest if I point out I'd be
> happier if ChucK was released under a BSD license and not a GPL
> license. That said, personally I prefer to write code under the GPLv3
> because I'd rather it didn't end up on the iphone.
>
> I agree it would be good to hear from the man himself! Ge, are you
> listening?
>
> Yes, that's really something I can't comment on.
> Yes there is built-in latency to get around these problems.
> "Realtime" is always going to be an illusion though, even in human
> perception the notion of the present is known as specious. But OSC
> NTP style timestamps are really accurate I think, and in practice the
> latency deadline is always met (as opposed to chuck's sample-accurate
> deadline, which I understand is not always met). Here's McCartney's
> take on this issue:
> http://lambda-the-ultimate.org/node/1431#comment-16362
Yes, I read that some time ago. I don't really understand what is meant by
"ChucK doesn't handle tempo". It's true that there is no such thing as a
"tempo" keyword but you can certainly make ChucK deal with tempo as long as
you can define what "tempo" means to you in a given context. There is no
inherent concept of a "note" or of "polyphony" in ChucK either but that
doesn't mean those aren't handled, at least not to me. What I found a bit
surprising is the notes about how there will be audio hickups once the cpu
is overloaded. Of course there will be; once we give the cpu too much to do
then there will be glitches in the sound, delays to the instructions on what
sound there should be, or both. This is the exact same for any system and we
can make design choices that affect in what way things will go wrong when
this happens. Clearly CK made different choices there from SC and either
system may be seen as failing more gracefully under different conditions.
McCartney is quite right to point out that longer computations can cause
audio glitches but I'd say that the alternative would be to give audio
precedence which would lead to "musical glitches" (notes that are late,
LFO's that are slow, etc) and no mention is made here of how ChucK's
behaviour also means that these computations may actually be doing (part of)
the dsp themselves in ChucK, in which case we may *want* the audio to wait
until they are done.
To be perfectly clear; I don't disagree at all with what was written there
but I do feel that either strategy may be preferable under some conditions.
It's a valid point, it relates to the internal architecture of ChucK and
it's of course always useful to contemplate such factors because knowing
more about a system will allow us to make better use of it or predict how it
will fail when it does but it's unclear to me why some people refer to that
post as a clear downside to ChucK because I don't think it is. It may well
make ChucK unsuitable for some applications but then again, other factors
will make SuperCollider a less suitable choice.
Much of what was said on this subject, including the linked post, was said
before the release of Ge's thesis. This is all a bit unfortunate because it
was only with Ge's thesis that there was a clear explanation of the internal
workings of ChucK and the relationship between the execution order of shreds
and the UGen graph. While I wouldn't go as far as saying that wrong claims
have been made I think there is a lot more clarity now on how things work
and why those choices were made.
> There are networks inside a computer too, just because it's outside a
> computer doesn't mean you can't make it work reliably enough. I have
> had problems doing timing over a wireless network though.
>
>
I agree, though it will depend on the level of reliability that you need. In
ChucK you can have two UGens with ChucK code in between them, treating the
signal of UGen A before it reaches UGen B in some way. If this arbitrary
treatment would need upsampling the signal to 16 times the samplerate,
performing these operations in ChucK code, then downsampling again before
handing out the result to B then you can and as long as your cpu can keep up
you are guaranteed that all calculations will be done in order (though you
will be getting a 1 sample delay because you can't interrupt the UGen graph
during a "tick"). You could -if you really wanted to- do that for a few
different such treatments and they will all be running in sync with each
other at a sub-sample resolution, for example if you'd like them to depend
on each other.
Now, this isn't a very realistic scenario because it would cost a lot of
cpu, but the syntax is prepared for that sort of timing resolution of the
code relative to the UGens while I don't think network messages are prepared
for that kind of stunt.
I'm not saying this is a inherently better choice; clearly in many scenarios
SC will be far lighter on the CPU without CK's benefits mattering but the
choices made do have real advantages in cases we might encounter. It
shouldn't be a great surprise that you can get very high resolution if you
are willing to spend a lot of CPU on it or that "sufficiently accurate
nearly all the time" will save cpu.
Personally I think none of this is anywhere near as relevant as what syntax
feels more natural to the individual user. I'm only covering this here
because I suspect the mentioned "flamewars" were only possible because of
mutual misunderstandings and I'll be the first to admit there is a lot about
SC I don't understand.
Yours,
Kas.
Received on Fri Jan 22 2010 - 17:49:04 GMT