Re: [PD] gpl vs creative commons

[IOhannes m zmoelnig]

Roman Haefeli wrote:
> 
> ask a lawyer to check in detail, if this is true. however, if licenses
> could cross 'levels of abstractions' in the sense of pd patches being
> affected by the license of pd, 

afaik, licenses do not cross "levels of abstractions".
however, if i have a collection of abstractions published under the GPL, 
then i think i don't cross this magical border.

next comes the question, what is the difference between an abstraction 
and an external non-abstraction object. afaik, GPL does not dissolve 
just because of languages used. (that is: porting of code from one 
language to another is (to my knowledge) not really affected by the GPL 
(e.g.: you can chose the license again) as it usually involves re-coding 
an algorithm rather than re-using pieces of code.; but this is unrelated 
to the language a library is written in)

finally, i am still unsure about the "static linking" clause, and how it 
affects an interpreted language.
i guess, if you have a  patch that depends on a GPL'ed pdlib, and you 
are distributing your patch with this library (e.g. for convencience 
reasons), then you are kind of _statically linking_ and thus your patch 
is automatically GPL'ed too.

but i really don't know

mfga.sd
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple instances of pd on os-x

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> On my machine, I can run two of these on the CLI and get two GUIs:

excuse my ignorance, but by "CLI" do you all mean _any_ terminal, or a 
special one?

> 
> /Applications/Pd-extended.app/Contents/MacOS/Pd-extended

interesting. any ideas why it does not work for steffen?

> 
> Another way is to make another copy of Pd with a different name, then  
> you can run them at the same time using all of the normal means (i.e.  
> Pd-1.app and Pd-2.app)

i would rather use my disk-space for something different :-)


mfg.asdr
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] vline~ question

[IOhannes m zmoelnig]

[EMAIL PROTECTED] wrote:
> Quoting Steffen Juul <[EMAIL PROTECTED]>:
> 
>>> i cannot follow you here at all.
>> Kyle wants to, correct me if i'm wrong, translate
> 
> seems like i talked babylonian here.
> i understood what kyle requested it, but i did not understand why he  
> wanted it.

too early in the morning:
i understood _what_ kyle requested, i did not understand _why_ he 
requested it.


fgmasdr.
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[Chris McCormick]

On Tue, Jan 29, 2008 at 09:08:18AM +0100, IOhannes m zmoelnig wrote:
> Roman Haefeli wrote:
> >
> >ask a lawyer to check in detail, if this is true. however, if licenses
> >could cross 'levels of abstractions' in the sense of pd patches being
> >affected by the license of pd, 
> 
> afaik, licenses do not cross "levels of abstractions".

In this particular case, Hans is wrong and you guys are right, but it's
quite complicated, depending on the type of work which is created and
the license of the software. Let me try to explain (IANAL and I am also
sleep deprived :) ).

Hans wrote: "I think that if you write a patch that uses a Pd library that
is covered by the GPL, technically, your patch is covered by the GPL."

This would only be true if you were:
a) Distributing the GPL library/external with your patch.
b) 'Linking' your patch with the original software.

On count (a) you generally don't distribute externals with your patch -
you expect people to download and install them themselves. Distributing
the patch on it's own is fine even if it used a commercially licensed
external - it's up to other users to procure a license for that
commercially licensed external in order to run your patch. Infact,
if you are not distributing the result, you can do whatever you want
(including linking commercial code or whatever) in the comfort of your
own home and nobody can stop you.

On count (b), I don't think anybody would 'link' a Pd patch with Pd
since that would require the patch to be turned into a data segment and
linked into the Pd binary and a special hook would be required to load the
linked binary segment directly into Pd at runtime instead of reading
it from a .pd text file. In other words, if someone made a stand-alone
application with the Pd file compiled into the binary and then distributed
that, then they would probably be required to adhere to the GPL license
of the externals used (e.g. if they used the linker program to link
the patch into the application). This area is quite fuzzy because some
people even contend whether dynamically linking things is covered by
the GPL - this has probably changed with GPL 3.0 which probably makes
it more explicit (but would still allow an interpereted .pd file no
problems at all). If the developer/distributor used pure Pd then they
wouldn't have to worry about that because it's BSD (except they would
have to flash the Pd license to the user at some point).

It's conceivable that someone would write some software that had
an EULA which specified that works created with that software were
covered by the same license as that software (crossing "levels of
abstraction"). Microsoft's Hotmail service does something like this -
when you create a hotmail account you agree that all data and emails
that pass through their server are owned by them. As for whether this
would stand up in court or not is a different matter. Especially
interesting in this regard is whether code is speech or not because as I
said, the type of work created matters a lot as different works are
considered in different ways under the law.

> however, if i have a collection of abstractions published under the GPL, 
> then i think i don't cross this magical border.

There is no "magical border". There is just different software with
different licenses and different types of works (which are treated
differently under the law) created with those bits of software. 99% of
the time you are going to be fine and you are going to be able to
license your work in whatever way you want, independently of the
software. When the work is itself a computer program it seems more
complicated but actually really isn't.

> next comes the question, what is the difference between an abstraction 
> and an external non-abstraction object. afaik, GPL does not dissolve 
> just because of languages used. (that is: porting of code from one 
> language to another is (to my knowledge) not really affected by the GPL 
> (e.g.: you can chose the license again) as it usually involves re-coding 
> an algorithm rather than re-using pieces of code.; but this is unrelated 
> to the language a library is written in)

Yep. The copyright covers the text of the source code. So if you
re-write the source code in a different language you have created a new
and different text. This is akin to re-writing a novel with different
words and characters and place names, but with the same basic plot. It's
completely legal. In the case of algorithms though, watch out because
under certain jurisdictions they may be covered by software patents
which will bite you in the ass.

The principal difference between and abstraction and an external is that
an external is 'linked' with the Pd binary (dynamically at runtime
usually) whilst an abstraction is interpereted. Interpereted works are
not covered by the GPL, but linked code is.

> finally, i am still unsure about the "static linking" clause, and how it 
> affects an interpreted language.

It doesn't in the case of th

Re: [PD] Jack OSX 0.75 Intel

[Simon Mills]

Hi dafydd

Its true it does work great - on 10.5.1 also. Just have to be aware  
that its only supporting 1 processor at the mo however. (that means  
everything running at the same time as Pd)

Wish I had the know-how to get in there and help out :-/

Who was responsible for it originally does anyone know?

cheers

On 29 Jan 2008, at 01:13, Dafydd Hughes wrote:

> Hey folks
>
> Downgrading works no problem - 0.74 is perfect.
>
> I'm on 10.4.
>
> Thanks for looking into this. If there's anything I can do, let me
> know - I'm into learning. I just need some pointers.
>
> cheers
> dafydd
>
> On Jan 28, 2008 6:19 PM, bsoisoi <[EMAIL PROTECTED]> wrote:
>> Are you trying to run Jack on 10.4 or 10.5?
>>
>>
>>
>> On Jan 28, 2008, at 6:07 PM, Hans-Christoph Steiner wrote:
>>
>>>
>>> Have you tried downgrading back to Jack .74 to see if it works
>>> again?  Pd's Jack support on Mac OS X doesn't really have a
>>> maintainer, so there might be some issues with it.
>>>
>>> .hc
>>>
>>> On Jan 28, 2008, at 12:25 PM, Dafydd Hughes wrote:
>>>
 Jack OSX 0.74 works like a dream. I spoke to the Jack developers  
 and
 they think it's a PD bug. I'm not smart enough to determine whether
 or
 not that's the case.

 cheers
 dafydd

 On Jan 28, 2008 12:19 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]>
 wrote:
>
> It doesn't work for me.  Did the old version work for you?  I  
> tried
> Pd-extended 0.39.3, 0.40.3, and Pd-vanilla 0.41.0.
>
> .hc
>
>
> On Jan 26, 2008, at 9:41 AM, Dafydd Hughes wrote:
>
>> Hi folks
>>
>> Has anybody got Pd running on an Intel mac using the new  
>> version of
>> Jack OSX (0.75)?
>>
>> cheers
>> dafydd
>>
>> --
>> www.sideshowmedia.ca
>> skype: chickeninthegrass
>>
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> listinfo/pd-list
>
>
>
> -
> ---
> 
>
> If you are not part of the solution, you are part of the problem.
>
>
>



 --
 www.sideshowmedia.ca
 skype: chickeninthegrass
>>>
>>>
>>>
>>> 
>>> 
>>>
>>> Man has survived hitherto because he was too ignorant to know how to
>>> realize his wishes.  Now that he can realize them, he must either
>>> change them, or perish.-William Carlos Williams
>>>
>>>
>>>
>>> ___
>>> PD-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
>
>
> -- 
> www.sideshowmedia.ca
> skype: chickeninthegrass
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[IOhannes m zmoelnig]

Chris McCormick wrote:
> 
>> however, if i have a collection of abstractions published under the GPL, 
>> then i think i don't cross this magical border.
> 
> There is no "magical border". There is just different software with
> different licenses and different types of works (which are treated
> differently under the law) created with those bits of software. 99% of

this is what i was referring to as "magical border" (trying to find a 
metaphor for "crossing the 'levels of abstractions'")

> Interpereted works are
> not covered by the GPL, but linked code is.

i cannot believe this.
one of the gpl-faqs at fsf [1] is "If a programming language interpreter 
has a license that is incompatible with the GPL, can I run GPL-covered 
programs on it?"
for me this (the mere existence of this faq with a different answer than 
"programs written in interpreted languages are not covered by the GPL") 
means, that programs running on an interpreter (that is: programs 
written in interpreted languages) _can_ be covered by GPL.


> 
>> finally, i am still unsure about the "static linking" clause, and how it 
>> affects an interpreted language.
> 
> It doesn't in the case of the GPL.


again quoting from [1]:

 > Another similar and very common case is to provide libraries with the
 > interpreter which are themselves interpreted. For instance, Perl comes
 > with many Perl modules, and a Java implementation comes with many Java
 > classes. These libraries and the programs that call them are always
 > dynamically linked together.
 >
 > A consequence is that if you choose to use GPL'd Perl modules or Java
 > classes in your program, you must release the program in a
 > GPL-compatible way, regardless of the license used in the Perl or Java
 > interpreter that the combined Perl or Java program will run on.

even though it does not mention Pd explicitely (probably because it is 
significantly less used than e.g. Perl), it clearly states that if 
"interpreted libraries" (perl modules, java classes, pd abstractions) 
published under GPL (again: how is this possible if the GPL is not valid 
for interpreted languages) are used, then your program (patch) must be 
"released in a GPL-compatible way".



> 
>> i guess, if you have a  patch that depends on a GPL'ed pdlib, and you 
>> are distributing your patch with this library (e.g. for convencience 
>> reasons), then you are kind of _statically linking_ and thus your patch 
>> is automatically GPL'ed too.
> 
> I really don't think so, unless you are actually using a linker program
> to link the .pd file with the Pd binary, which is very unlikely. If I am
> wrong then ALL YOUR BASE BELONG TO MILLER and I am switching to
> supercollider. :)


since when does statically linking defines ownership?
how is the license of supercollider (GPL) different from Pd's license 
(BSD), that it would prevent all of your sc code belong to james mccartney?


apart from that i largely agree.


mfga.sdr
IOhannes



[1] http://www.fsf.org/licensing/licenses/gpl-faq.html


> 
> Best,
> 
> Chris.
> 
> ---
> http://mccormick.cx
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[LAC2008]

Dear all,

The Linux Audio Conference 2008 in Cologne (Feb 28th - Mar 2nd 2008)
is just one month away now. The programme is shaping up, concerts are
being organized and coffee is about to be ordered.

To help us with planning the LAC2008 we kindly ask you to register now
at the conference website. This helps us to estimate how many visitors
we may expect, what individuals the audience is made of, and allows to
produce name tags for all attendees so that it becomes easier to
identify each other.

To register, please use the "Registration" form at
http://lac.linuxaudio.org

Also we now have put accommodation info plus some maps of the
conference location online. You can find these on
http://lac.linuxaudio.org under "Visitor Info". 

Finally if you're living in Cologne or nearby: We are looking for
volunteers who would like to help out in any way, e.g. to host artists
and paper presenters in their flat. If you want to offer your help,
please contact the LAC2008 orga team at [EMAIL PROTECTED] 

The LAC2008 chair is looking forward to have another great conference
with you all.

All the best
-- 
 Frank Barknecht and Martin Rumori
 Chairs of LAC2008

___
PD-announce mailing list
[EMAIL PROTECTED]
http://lists.puredata.info/listinfo/pd-announce

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Jack OSX 0.75 Intel

[Hans-Christoph Steiner]

You may not have the knowledge to fix Jack now, but you can learn.   
Most of the Pd devs did just that in order to improve Pd.  When I  
started, I'd never touched Tcl and I had taken one class on C eight  
years previous to that and hadn't touched since at all in the time in  
between.  So I basically learned C and Tcl to hack on Pd.

.hc

On Jan 29, 2008, at 4:28 AM, Simon Mills wrote:

> Hi dafydd
>
> Its true it does work great - on 10.5.1 also. Just have to be aware
> that its only supporting 1 processor at the mo however. (that means
> everything running at the same time as Pd)
>
> Wish I had the know-how to get in there and help out :-/
>
> Who was responsible for it originally does anyone know?
>
> cheers
>
> On 29 Jan 2008, at 01:13, Dafydd Hughes wrote:
>
>> Hey folks
>>
>> Downgrading works no problem - 0.74 is perfect.
>>
>> I'm on 10.4.
>>
>> Thanks for looking into this. If there's anything I can do, let me
>> know - I'm into learning. I just need some pointers.
>>
>> cheers
>> dafydd
>>
>> On Jan 28, 2008 6:19 PM, bsoisoi <[EMAIL PROTECTED]> wrote:
>>> Are you trying to run Jack on 10.4 or 10.5?
>>>
>>>
>>>
>>> On Jan 28, 2008, at 6:07 PM, Hans-Christoph Steiner wrote:
>>>

 Have you tried downgrading back to Jack .74 to see if it works
 again?  Pd's Jack support on Mac OS X doesn't really have a
 maintainer, so there might be some issues with it.

 .hc

 On Jan 28, 2008, at 12:25 PM, Dafydd Hughes wrote:

> Jack OSX 0.74 works like a dream. I spoke to the Jack developers
> and
> they think it's a PD bug. I'm not smart enough to determine  
> whether
> or
> not that's the case.
>
> cheers
> dafydd
>
> On Jan 28, 2008 12:19 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]>
> wrote:
>>
>> It doesn't work for me.  Did the old version work for you?  I
>> tried
>> Pd-extended 0.39.3, 0.40.3, and Pd-vanilla 0.41.0.
>>
>> .hc
>>
>>
>> On Jan 26, 2008, at 9:41 AM, Dafydd Hughes wrote:
>>
>>> Hi folks
>>>
>>> Has anybody got Pd running on an Intel mac using the new
>>> version of
>>> Jack OSX (0.75)?
>>>
>>> cheers
>>> dafydd
>>>
>>> --
>>> www.sideshowmedia.ca
>>> skype: chickeninthegrass
>>>
>>> ___
>>> PD-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http:// 
>>> lists.puredata.info/
>>> listinfo/pd-list
>>
>>
>>
>> - 
>> 
>> ---
>> 
>>
>> If you are not part of the solution, you are part of the problem.
>>
>>
>>
>
>
>
> --
> www.sideshowmedia.ca
> skype: chickeninthegrass



 --- 
 -
 

 Man has survived hitherto because he was too ignorant to know  
 how to
 realize his wishes.  Now that he can realize them, he must either
 change them, or perish.-William Carlos Williams



 ___
 PD-list@iem.at mailing list
 UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
 listinfo/pd-list
>>>
>>>
>>
>>
>>
>> -- 
>> www.sideshowmedia.ca
>> skype: chickeninthegrass
>>
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


   http://at.or.at/hans/



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Jack OSX 0.75 Intel

[Dafydd Hughes]

Okay so hook me up. (That's kinda what I wanted to hear.) I'll get the
source for both. Any hints about where I might start looking?

Is the idea that I'd write a patch?

This may take  _while_.

cheers
dafydd

On Jan 29, 2008 9:42 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>
> You may not have the knowledge to fix Jack now, but you can learn.
> Most of the Pd devs did just that in order to improve Pd.  When I
> started, I'd never touched Tcl and I had taken one class on C eight
> years previous to that and hadn't touched since at all in the time in
> between.  So I basically learned C and Tcl to hack on Pd.
>
> .hc
>
>
> On Jan 29, 2008, at 4:28 AM, Simon Mills wrote:
>
> > Hi dafydd
> >
> > Its true it does work great - on 10.5.1 also. Just have to be aware
> > that its only supporting 1 processor at the mo however. (that means
> > everything running at the same time as Pd)
> >
> > Wish I had the know-how to get in there and help out :-/
> >
> > Who was responsible for it originally does anyone know?
> >
> > cheers
> >
> > On 29 Jan 2008, at 01:13, Dafydd Hughes wrote:
> >
> >> Hey folks
> >>
> >> Downgrading works no problem - 0.74 is perfect.
> >>
> >> I'm on 10.4.
> >>
> >> Thanks for looking into this. If there's anything I can do, let me
> >> know - I'm into learning. I just need some pointers.
> >>
> >> cheers
> >> dafydd
> >>
> >> On Jan 28, 2008 6:19 PM, bsoisoi <[EMAIL PROTECTED]> wrote:
> >>> Are you trying to run Jack on 10.4 or 10.5?
> >>>
> >>>
> >>>
> >>> On Jan 28, 2008, at 6:07 PM, Hans-Christoph Steiner wrote:
> >>>
> 
>  Have you tried downgrading back to Jack .74 to see if it works
>  again?  Pd's Jack support on Mac OS X doesn't really have a
>  maintainer, so there might be some issues with it.
> 
>  .hc
> 
>  On Jan 28, 2008, at 12:25 PM, Dafydd Hughes wrote:
> 
> > Jack OSX 0.74 works like a dream. I spoke to the Jack developers
> > and
> > they think it's a PD bug. I'm not smart enough to determine
> > whether
> > or
> > not that's the case.
> >
> > cheers
> > dafydd
> >
> > On Jan 28, 2008 12:19 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]>
> > wrote:
> >>
> >> It doesn't work for me.  Did the old version work for you?  I
> >> tried
> >> Pd-extended 0.39.3, 0.40.3, and Pd-vanilla 0.41.0.
> >>
> >> .hc
> >>
> >>
> >> On Jan 26, 2008, at 9:41 AM, Dafydd Hughes wrote:
> >>
> >>> Hi folks
> >>>
> >>> Has anybody got Pd running on an Intel mac using the new
> >>> version of
> >>> Jack OSX (0.75)?
> >>>
> >>> cheers
> >>> dafydd
> >>>
> >>> --
> >>> www.sideshowmedia.ca
> >>> skype: chickeninthegrass
> >>>
> >>> ___
> >>> PD-list@iem.at mailing list
> >>> UNSUBSCRIBE and account-management -> http://
> >>> lists.puredata.info/
> >>> listinfo/pd-list
> >>
> >>
> >>
> >> -
> >> 
> >> ---
> >> 
> >>
> >> If you are not part of the solution, you are part of the problem.
> >>
> >>
> >>
> >
> >
> >
> > --
> > www.sideshowmedia.ca
> > skype: chickeninthegrass
> 
> 
> 
>  ---
>  -
>  
> 
>  Man has survived hitherto because he was too ignorant to know
>  how to
>  realize his wishes.  Now that he can realize them, he must either
>  change them, or perish.-William Carlos Williams
> 
> 
> 
>  ___
>  PD-list@iem.at mailing list
>  UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>  listinfo/pd-list
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> www.sideshowmedia.ca
> >> skype: chickeninthegrass
> >>
> >> ___
> >> PD-list@iem.at mailing list
> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> >> listinfo/pd-list
> >
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> > listinfo/pd-list
>
>
>
> 
> 
>
>http://at.or.at/hans/
>
>
>



-- 
www.sideshowmedia.ca
skype: chickeninthegrass

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Hans-Christoph Steiner]

Miller is giving a keynote, so it seems it could be the Pd year at  
LAC.  I'll be presenting the NY Times project that I recently worked  
on.  Who else will be there?

.hc

On Jan 29, 2008, at 6:33 AM, LAC2008 wrote:

> Dear all,
>
> The Linux Audio Conference 2008 in Cologne (Feb 28th - Mar 2nd 2008)
> is just one month away now. The programme is shaping up, concerts are
> being organized and coffee is about to be ordered.
>
> To help us with planning the LAC2008 we kindly ask you to register now
> at the conference website. This helps us to estimate how many visitors
> we may expect, what individuals the audience is made of, and allows to
> produce name tags for all attendees so that it becomes easier to
> identify each other.
>
> To register, please use the "Registration" form at
> http://lac.linuxaudio.org
>
> Also we now have put accommodation info plus some maps of the
> conference location online. You can find these on
> http://lac.linuxaudio.org under "Visitor Info".
>
> Finally if you're living in Cologne or nearby: We are looking for
> volunteers who would like to help out in any way, e.g. to host artists
> and paper presenters in their flat. If you want to offer your help,
> please contact the LAC2008 orga team at [EMAIL PROTECTED]
>
> The LAC2008 chair is looking forward to have another great conference
> with you all.
>
> All the best
> -- 
>  Frank Barknecht and Martin Rumori
>  Chairs of LAC2008
>
> ___
> PD-announce mailing list
> [EMAIL PROTECTED]
> http://lists.puredata.info/listinfo/pd-announce
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


Man has survived hitherto because he was too ignorant to know how to  
realize his wishes.  Now that he can realize them, he must either  
change them, or perish.-William Carlos Williams



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Jack OSX 0.75 Intel

[Hans-Christoph Steiner]

I'd say the first part is really clearly documenting the bug, and  
trying to narrow down where the cause it.  That means testing  
different versions, different setups, etc.

.hc

On Jan 29, 2008, at 9:49 AM, Dafydd Hughes wrote:

> Okay so hook me up. (That's kinda what I wanted to hear.) I'll get the
> source for both. Any hints about where I might start looking?
>
> Is the idea that I'd write a patch?
>
> This may take  _while_.
>
> cheers
> dafydd
>
> On Jan 29, 2008 9:42 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>>
>> You may not have the knowledge to fix Jack now, but you can learn.
>> Most of the Pd devs did just that in order to improve Pd.  When I
>> started, I'd never touched Tcl and I had taken one class on C eight
>> years previous to that and hadn't touched since at all in the time in
>> between.  So I basically learned C and Tcl to hack on Pd.
>>
>> .hc
>>
>>
>> On Jan 29, 2008, at 4:28 AM, Simon Mills wrote:
>>
>>> Hi dafydd
>>>
>>> Its true it does work great - on 10.5.1 also. Just have to be aware
>>> that its only supporting 1 processor at the mo however. (that means
>>> everything running at the same time as Pd)
>>>
>>> Wish I had the know-how to get in there and help out :-/
>>>
>>> Who was responsible for it originally does anyone know?
>>>
>>> cheers
>>>
>>> On 29 Jan 2008, at 01:13, Dafydd Hughes wrote:
>>>
 Hey folks

 Downgrading works no problem - 0.74 is perfect.

 I'm on 10.4.

 Thanks for looking into this. If there's anything I can do, let me
 know - I'm into learning. I just need some pointers.

 cheers
 dafydd

 On Jan 28, 2008 6:19 PM, bsoisoi <[EMAIL PROTECTED]> wrote:
> Are you trying to run Jack on 10.4 or 10.5?
>
>
>
> On Jan 28, 2008, at 6:07 PM, Hans-Christoph Steiner wrote:
>
>>
>> Have you tried downgrading back to Jack .74 to see if it works
>> again?  Pd's Jack support on Mac OS X doesn't really have a
>> maintainer, so there might be some issues with it.
>>
>> .hc
>>
>> On Jan 28, 2008, at 12:25 PM, Dafydd Hughes wrote:
>>
>>> Jack OSX 0.74 works like a dream. I spoke to the Jack developers
>>> and
>>> they think it's a PD bug. I'm not smart enough to determine
>>> whether
>>> or
>>> not that's the case.
>>>
>>> cheers
>>> dafydd
>>>
>>> On Jan 28, 2008 12:19 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]>
>>> wrote:

 It doesn't work for me.  Did the old version work for you?  I
 tried
 Pd-extended 0.39.3, 0.40.3, and Pd-vanilla 0.41.0.

 .hc


 On Jan 26, 2008, at 9:41 AM, Dafydd Hughes wrote:

> Hi folks
>
> Has anybody got Pd running on an Intel mac using the new
> version of
> Jack OSX (0.75)?
>
> cheers
> dafydd
>
> --
> www.sideshowmedia.ca
> skype: chickeninthegrass
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://
> lists.puredata.info/
> listinfo/pd-list



 --- 
 --
 
 ---
 

 If you are not part of the solution, you are part of the  
 problem.



>>>
>>>
>>>
>>> --
>>> www.sideshowmedia.ca
>>> skype: chickeninthegrass
>>
>>
>>
>> - 
>> --
>> -
>> 
>>
>> Man has survived hitherto because he was too ignorant to know
>> how to
>> realize his wishes.  Now that he can realize them, he must either
>> change them, or perish.-William Carlos Williams
>>
>>
>>
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> listinfo/pd-list
>
>



 --
 www.sideshowmedia.ca
 skype: chickeninthegrass

 ___
 PD-list@iem.at mailing list
 UNSUBSCRIBE and account-management -> http://lists.puredata.info/
 listinfo/pd-list
>>>
>>>
>>> ___
>>> PD-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>>> listinfo/pd-list
>>
>>
>>
>> - 
>> ---
>> 
>>
>>http://at.or.at/hans/
>>
>>
>>
>
>
>
> -- 
> www.sideshowmedia.ca
> skype: chickeninthegrass



 


If you are not part of the solution, you are pa

Re: [PD] multiple instances of pd on os-x

[Hans-Christoph Steiner]

On Jan 29, 2008, at 3:11 AM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> On my machine, I can run two of these on the CLI and get two GUIs:
>
> excuse my ignorance, but by "CLI" do you all mean _any_ terminal,  
> or a special one?

Yup, any shell.

.hc

>> /Applications/Pd-extended.app/Contents/MacOS/Pd-extended
>
> interesting. any ideas why it does not work for steffen?
>
>> Another way is to make another copy of Pd with a different name,  
>> then  you can run them at the same time using all of the normal  
>> means (i.e.  Pd-1.app and Pd-2.app)
>
> i would rather use my disk-space for something different :-)
>
>
> mfg.asdr
> IOhannes



 


I spent 33 years and four months in active military service and  
during that period I spent most of my time as a high class muscle man  
for Big Business, for Wall Street and the bankers.  - General  
Smedley Butler



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] one more boring computation-time cuestion of mine...

[Miller Puckette]

Just a guess... maybe allocating all that memory is forcing the OS to
page other apps out.  (I'm not sure how much memory is getting used but
if it's more than 1/4 of the system total it's possible that is slowing
stuff down.)

cheers
Miller

On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote:
> Hi,
> 
> Suppose I create a [sample] abstraction that basically contains a
> [table] to store a sound sample, and a [soundfiler] to read it from a
> file.
> 
> One of the reasons for creating such a "trivial" abstraction is that
> it has a GOP GUI with
> -a symbolbox where you can write and see the filename
> -a test button that plays the sample.
> 
> Now suppose the test part is implemented like this (simplified):
> 
> [r $1-test]
> |
> [tabplay~ $1]
> |
> [throw~ sampletestout]
> 
> 
> ($1 is the name of the sample, i.e. the name of the table, and the GUI
> is supposed to have a bng sending to $1-test)
> 
> Obviously, to avoid unnecessary cpu-usage, that would become enormous
> if I have many sample instances, I will include the necessary patching
> in the abstraction in order to [switch~] it on only when playing, and
> off when not. Usually you'll be testing at most one sample at the same
> time.
> 
> Now the question is: in case there are N [sample]s in my patch,
> Is it possible that the time needed to load ONE sample (sending a
> [read...( message to the [soundfiler]) increases with N???
> If so, why?
> 
> The fact is that I have been using such an abstraction very much, and
> have a great number of [sample]s in my patch, and started to notice
> that loading all the samples was terribly slow.
> Then, without thinking it had any relation to this, I realised I could
> easily remove all the "~" part from the sample abstraction, by
> implementing a unique [sampletester] and having [sample]s sending him
> messages to test one sample.
> I did this, and removed the [tabplay~] thing from the [sample]
> abstraction, and now the loading of samples seems to be enormously
> faster...
> 
> 
> 
> -- 
> Matteo Sisti Sette
> [EMAIL PROTECTED]
> http://www.matteosistisette.com
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[Hans-Christoph Steiner]

On Jan 29, 2008, at 3:08 AM, IOhannes m zmoelnig wrote:

> Roman Haefeli wrote:
>> ask a lawyer to check in detail, if this is true. however, if  
>> licenses
>> could cross 'levels of abstractions' in the sense of pd patches being
>> affected by the license of pd,
>
> afaik, licenses do not cross "levels of abstractions".
> however, if i have a collection of abstractions published under the  
> GPL, then i think i don't cross this magical border.
>
> next comes the question, what is the difference between an  
> abstraction and an external non-abstraction object. afaik, GPL does  
> not dissolve just because of languages used. (that is: porting of  
> code from one language to another is (to my knowledge) not really  
> affected by the GPL (e.g.: you can chose the license again) as it  
> usually involves re-coding an algorithm rather than re-using pieces  
> of code.; but this is unrelated to the language a library is  
> written in)
>
> finally, i am still unsure about the "static linking" clause, and  
> how it affects an interpreted language.
> i guess, if you have a  patch that depends on a GPL'ed pdlib, and  
> you are distributing your patch with this library (e.g. for  
> convencience reasons), then you are kind of _statically linking_  
> and thus your patch is automatically GPL'ed too.
>
> but i really don't know
>
> mfga.sd
> IOhannes

Dynamically linked libraries also trigger the GPL.  For example, most  
Linux kernel modules are dynamically linked into the kernel these  
days, and they definitely required to be GPL.

PD patches are not a clear case like the Cubase example because  
Cubase projects are clearly not programming.  If you consider a Pd  
patch a program, then it means it triggers the share-alike/copyleft  
conditions of the GPL.  When you load a patch, you are forcing all of  
the compiled objects to be dynamically linked in, so the patch is  
definitely linked.

.hc


 


"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White





___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> On Jan 29, 2008, at 3:08 AM, IOhannes m zmoelnig wrote:
>>
>> but i really don't know
>>
>> mfga.sd
>> IOhannes
> 
> Dynamically linked libraries also trigger the GPL.  For example, most  

yeah; i wanted to stress that shipping a patch with abstraction 
dependencies could even be considered as static linking - because people 
seem to think that static linking enforces the GPL more than dynamic 
linking. (which does say nothing about whether this is true)

> Linux kernel modules are dynamically linked into the kernel these  
> days, and they definitely required to be GPL.

but there _are_ non-GPL'ed kernel-modules.
even though they are disliked.

mfg.,asdr.
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] plugin~ problems (ladspa-linux) - strange behavior

[Jerome Tuncer]

Hi glerm,

This has already been discussed a a few times I think. It happened to me 
as well, the workaround I found at the time was to start pd with the 
"unset LANG" prepended i.e. :

$ unset LANG
$ ./pd

Alternatively :

$ unset LANG && ./pd

Does pd started from a terminal throw you an error like this one :

bad screen distance "124,00"
can't find an indexable and selectable item ".x8249400.t827ec80"
can't find an indexable and selectable item ".x8249400.t827ec80"
bad screen distance "124,00"

?

++


Jé

glerm soares a écrit :
> 
> 
> 2008/1/28, glerm soares <[EMAIL PROTECTED] >:
> 
> hello,
> 
> I just compiled the plugin~ version of cvs today, and the
> compilation seemed to be ok.
> 
> 
> my kernel:
> Linux ubuntu 2.6.22-14-rt #1 SMP PREEMPT RT Tue Dec 18 10:01:34 UTC 2007 
> i686 GNU/Linux
>  
> (based on "gutsy" repositories)
> 
> 
> 
> 
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] High cpu usage

[Javier Garcia]

Hi Hans, 

Here you have the patch..

Im using a core duo 2 2,16 GHz and UbuntuStudio 7.04.

Im
not worried about that high cpu usage, because with the values i said
(1, 2, 3, 4, 5, 6, 8) the movie is played veryveryvery fast, so maybe
is something normal... 

What surprise me, is that the increase of the cpu usage is exponential (or 
similar) around those values.

Regards

Javi

___
www.myspace.com/vjgarff

CC: pd-list@iem.at
From: [EMAIL PROTECTED]
Subject: Re: [PD] High cpu usage
Date: Mon, 28 Jan 2008 12:22:20 -0500
To: [EMAIL PROTECTED]


Hey, There is no patch attached...Do you have a Pentium 4 computer?  Which 
version of Pd. Perhaps its a denormal bughc
On Jan 26, 2008, at 11:37 AM, Javier Garcia wrote:Hi,

the patch attached gets high exponentially the cpu usage when i decrease a 
number box to low values.

any idea? or should keep it in values from 10?

Regards

GARFF


www.myspace.com/vjgarff

Tecnología, moda, motor, viajes,.suscríbete a nuestros boletines para estar 
siempre a la última MSN [EMAIL PROTECTED] mailing listUNSUBSCRIBE and 
account-management -> http://lists.puredata.info/listinfo/pd-list 
 

The arc of history bends towards justice. - Dr. Martin Luther King, Jr. 

_
Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar 
siempre a la última
Guapos y guapas, clips musicales y estrenos de cine. 

patch.pd
Description: application/puredata
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple instances of pd on os-x

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> 
> On Jan 29, 2008, at 3:11 AM, IOhannes m zmoelnig wrote:
> 
>> Hans-Christoph Steiner wrote:
>>> On my machine, I can run two of these on the CLI and get two GUIs:
>>
>> excuse my ignorance, but by "CLI" do you all mean _any_ terminal, or a 
>> special one?
> 
> Yup, any shell.
> 

thanks for clarification


fgmasdr.
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[Hans-Christoph Steiner]

On Jan 29, 2008, at 10:05 AM, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> On Jan 29, 2008, at 3:08 AM, IOhannes m zmoelnig wrote:
>>>
>>> but i really don't know
>>>
>>> mfga.sd
>>> IOhannes
>> Dynamically linked libraries also trigger the GPL.  For example, most
>
> yeah; i wanted to stress that shipping a patch with abstraction  
> dependencies could even be considered as static linking - because  
> people seem to think that static linking enforces the GPL more than  
> dynamic linking. (which does say nothing about whether this is true)
>
>> Linux kernel modules are dynamically linked into the kernel these   
>> days, and they definitely required to be GPL.
>
> but there _are_ non-GPL'ed kernel-modules.
> even though they are disliked.

Yes, and they are also technically in violation of the GPL, AFAIK.  I  
imagine that Linus and the FSF has not enforced it because it could  
be counterproductive.

.hc

 


Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war  
on terrorism.- retired U.S. Army general, William Odom



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple instances of pd on os-x

[Steffen Juul]

On 29/01/2008, at 9.11, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> /Applications/Pd-extended.app/Contents/MacOS/Pd-extended
>
> interesting. any ideas why it does not work for steffen?

I tried out Pd-0.41-0. Hans tried Pd-extended. Pd-0.41-0 is build by  
Miller. Pd-extended is build by Hans. While it's still on the same  
operation system, it's not the same build system.  I think the  
differentness is in how the GUI and the core of Pd are tied to each  
other.

I still haven't worked out how Miller builds on Mac OS X, i.e. makes  
a so called "app bundle". It's not a matter of just running './ 
configure & make & make install' since the install makefile target  
doesn't make a app bundle. - In fact that operation is nowhere  
mentioned in the Makefile that ships with the src.

I'm not saying this to just cough up shit. But to say that the way Pd- 
extended is build for Mac OS X might be more in the Mac way of doing  
things. That is that running /path/to/some.app/Contents/MacOS/ 
executable might even be the default or standard way of launching an  
application (on Mac OS X). But again i'm no Mac witch.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Georg Holzmann]

Hans-Christoph Steiner schrieb:
> Miller is giving a keynote, so it seems it could be the Pd year at  
> LAC.  I'll be presenting the NY Times project that I recently worked  
> on.  Who else will be there?

basically all the pd-people from graz !

LG
Georg

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Steffen Juul]

On 29/01/2008, at 17.10, Hans-Christoph Steiner wrote:

>  Who else will be there?

I will yet again follow the video cast. (Hopefully the screen with  
the presentation will be in focus rather then the speaker.)

Lovely artwork. Especially the poster. Kind of the same ascetics as  
the covers of some of the records from Esel and Karaoke Kalk (which  
are (or were) Cologne based, iirc). Who did it?
  

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] one more boring computation-time cuestion of mine...

[Matteo Sisti Sette]

> Just a guess... maybe allocating all that memory is forcing the OS to
> page other apps out.

I can't discard that, but...
Correct me if I am wrong: if that was the case, removing the [tabplay~]s 
shouldn't make a difference, should it?

I removed the tabplay~s but the number of tables and size of the sound 
samples are the same, and now it loads all samples much much faster.

To "rephrase" the whole problem in a simpler way, consider this:

A) N occurrences of:
[table table-K][soundfiler]

[tabplay~ table-K]

(with K=1,2,...,N)

Versus this:

B) N occurrences of just [table table-K] and [soundfiler]
and only one unique [tabplay~].

When I "load" samples, each soundfiler receives a
[read -resize something.wav table-K( message.

In case (A) loading all samples is much slower.


My guess was the following:
"Every time a soundfiler loads a file into an array, and therefore resizes 
it, the DSP graph (or SOMETHING) is recomputed. In PD's data structures, for 
some reason each table has some sort of link to any [tabplay~] or [tabread~] 
object "attached" to it (in this case one tabplay per table). So when 
recomputing the whole data structure (once per table resize) there's some 
kind of operation that is being done N times in case A and zero or one times 
in case B."

 Or maybe the first part is correct and the second part is much 
simpler?:
"Evert time a soundfiler loads a file into an array, and therefore resizes 
it, the DSP graph is recomputed, and the time needed to do this is 
proportional to the number of  existing "~" objects. Therefore removing a 
big number of useless [tabplay~]s is reducing the size of the graph and time 
needed to calculate it."


Is any of my two guesses even near to correct?

Thanks a lot
m.


On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote:
> Hi,
>
> Suppose I create a [sample] abstraction that basically contains a
> [table] to store a sound sample, and a [soundfiler] to read it from a
> file.
>
> One of the reasons for creating such a "trivial" abstraction is that
> it has a GOP GUI with
> -a symbolbox where you can write and see the filename
> -a test button that plays the sample.
>
> Now suppose the test part is implemented like this (simplified):
>
> [r $1-test]
> |
> [tabplay~ $1]
> |
> [throw~ sampletestout]
>
>
> ($1 is the name of the sample, i.e. the name of the table, and the GUI
> is supposed to have a bng sending to $1-test)
>
> Obviously, to avoid unnecessary cpu-usage, that would become enormous
> if I have many sample instances, I will include the necessary patching
> in the abstraction in order to [switch~] it on only when playing, and
> off when not. Usually you'll be testing at most one sample at the same
> time.
>
> Now the question is: in case there are N [sample]s in my patch,
> Is it possible that the time needed to load ONE sample (sending a
> [read...( message to the [soundfiler]) increases with N???
> If so, why?
>
> The fact is that I have been using such an abstraction very much, and
> have a great number of [sample]s in my patch, and started to notice
> that loading all the samples was terribly slow.
> Then, without thinking it had any relation to this, I realised I could
> easily remove all the "~" part from the sample abstraction, by
> implementing a unique [sampletester] and having [sample]s sending him
> messages to test one sample.
> I did this, and removed the [tabplay~] thing from the [sample]
> abstraction, and now the loading of samples seems to be enormously
> faster...
>
>
>
> -- 
> Matteo Sisti Sette
> [EMAIL PROTECTED]
> http://www.matteosistisette.com
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Andre Schmidt]

On Tue, 2008-01-29 at 18:06 +0100, Steffen Juul wrote:
> On 29/01/2008, at 17.10, Hans-Christoph Steiner wrote:
> 
> >  Who else will be there?
> 
> I will yet again follow the video cast. (Hopefully the screen with  
> the presentation will be in focus rather then the speaker.)

or:

|presenter||
|cam  ||
| ||
|_||
|  |
|  |
|  |
|  |
|  |
|screen video  |
|__|

.andre


> 
> Lovely artwork. Especially the poster. Kind of the same ascetics as  
> the covers of some of the records from Esel and Karaoke Kalk (which  
> are (or were) Cologne based, iirc). Who did it?
>   
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Steffen Juul]

On 29/01/2008, at 20.15, Andre Schmidt wrote:

>
> On Tue, 2008-01-29 at 18:06 +0100, Steffen Juul wrote:
>>
>> I will yet again follow the video cast. (Hopefully the screen with
>> the presentation will be in focus rather then the speaker.)
>
> or:
> 
> |presenter||
> |cam  ||
> | ||
> |_||
> |  |
> |  |
> |  |
> |  |
> |  |
> |screen video  |
> |__|


Yeah. Thats what i'm hoping too.

Last year the web casting team said they had thought about it, but  
couldn't do it due to their limited budget. I have no idea how to  
suggest this idea to the 2008 team.

I recall watching a videocast of Dafydd doing a talk on Pd at some  
canadian FLOSS meeting-conference-something. It was my impression it  
was a really good talk and presentation of Pd and what Pd could be  
used of. But sadly it was almost useless as i could se what was going  
on at the screen.
Last years LAC wasn't too bad as the slides used were published as  
PDF and it was announce on IRC when there was a page change. Problem  
being that many presentations include things in the screen video that  
is not slides. This could fx. be a running Pd patch (as Miller did a  
lot at ICMC07).

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] one more boring computation-time cuestion of mine...

[Charles Henry]

Another diagnostic idea: try comparing the behavior during loading
with audio switched on and off.
my guess is:
if this is a memory issue, it won't make a difference
if it's the computations involved with big #'s of tabplay~, then it
will be faster with audio off

Chuck

On Jan 29, 2008 1:21 PM, Matteo Sisti Sette <[EMAIL PROTECTED]> wrote:
>
> > Just a guess... maybe allocating all that memory is forcing the OS to
> > page other apps out.
>
> I can't discard that, but...
> Correct me if I am wrong: if that was the case, removing the [tabplay~]s
> shouldn't make a difference, should it?
>
> I removed the tabplay~s but the number of tables and size of the sound
> samples are the same, and now it loads all samples much much faster.
>
> To "rephrase" the whole problem in a simpler way, consider this:
>
> A) N occurrences of:
> [table table-K][soundfiler]
>
> [tabplay~ table-K]
>
> (with K=1,2,...,N)
>
> Versus this:
>
> B) N occurrences of just [table table-K] and [soundfiler]
> and only one unique [tabplay~].
>
> When I "load" samples, each soundfiler receives a
> [read -resize something.wav table-K( message.
>
> In case (A) loading all samples is much slower.
>
>
> My guess was the following:
> "Every time a soundfiler loads a file into an array, and therefore resizes
> it, the DSP graph (or SOMETHING) is recomputed. In PD's data structures, for
> some reason each table has some sort of link to any [tabplay~] or [tabread~]
> object "attached" to it (in this case one tabplay per table). So when
> recomputing the whole data structure (once per table resize) there's some
> kind of operation that is being done N times in case A and zero or one times
> in case B."
>
>  Or maybe the first part is correct and the second part is much
> simpler?:
> "Evert time a soundfiler loads a file into an array, and therefore resizes
> it, the DSP graph is recomputed, and the time needed to do this is
> proportional to the number of  existing "~" objects. Therefore removing a
> big number of useless [tabplay~]s is reducing the size of the graph and time
> needed to calculate it."
>
>
> Is any of my two guesses even near to correct?
>
> Thanks a lot
> m.
>
>
>
> On Mon, Jan 28, 2008 at 04:52:56PM +0100, matteo sisti sette wrote:
> > Hi,
> >
> > Suppose I create a [sample] abstraction that basically contains a
> > [table] to store a sound sample, and a [soundfiler] to read it from a
> > file.
> >
> > One of the reasons for creating such a "trivial" abstraction is that
> > it has a GOP GUI with
> > -a symbolbox where you can write and see the filename
> > -a test button that plays the sample.
> >
> > Now suppose the test part is implemented like this (simplified):
> >
> > [r $1-test]
> > |
> > [tabplay~ $1]
> > |
> > [throw~ sampletestout]
> >
> >
> > ($1 is the name of the sample, i.e. the name of the table, and the GUI
> > is supposed to have a bng sending to $1-test)
> >
> > Obviously, to avoid unnecessary cpu-usage, that would become enormous
> > if I have many sample instances, I will include the necessary patching
> > in the abstraction in order to [switch~] it on only when playing, and
> > off when not. Usually you'll be testing at most one sample at the same
> > time.
> >
> > Now the question is: in case there are N [sample]s in my patch,
> > Is it possible that the time needed to load ONE sample (sending a
> > [read...( message to the [soundfiler]) increases with N???
> > If so, why?
> >
> > The fact is that I have been using such an abstraction very much, and
> > have a great number of [sample]s in my patch, and started to notice
> > that loading all the samples was terribly slow.
> > Then, without thinking it had any relation to this, I realised I could
> > easily remove all the "~" part from the sample abstraction, by
> > implementing a unique [sampletester] and having [sample]s sending him
> > messages to test one sample.
> > I did this, and removed the [tabplay~] thing from the [sample]
> > abstraction, and now the loading of samples seems to be enormously
> > faster...
> >
> >
> >
> > --
> > Matteo Sisti Sette
> > [EMAIL PROTECTED]
> > http://www.matteosistisette.com
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Frank Barknecht]

Hallo,
Steffen Juul hat gesagt: // Steffen Juul wrote:

> On 29/01/2008, at 17.10, Hans-Christoph Steiner wrote:
> 
> >  Who else will be there?
> 
> I will yet again follow the video cast. (Hopefully the screen with  
> the presentation will be in focus rather then the speaker.)
> 
> Lovely artwork. Especially the poster. Kind of the same ascetics as  
> the covers of some of the records from Esel and Karaoke Kalk (which  
> are (or were) Cologne based, iirc). Who did it?

All LAC2008 design is by an ex-student of KHM: Christoph Haag. Also
the logo, which will be available as a t-shirt during LAC.  The
Cologne-based minimal techno label "Speicher" (sublabel of Kompakt)
also used a variation of the city arms as its logo[1]. May be a
tradition by now ...

Btw. the LAC poster you can print yourself, of course, using the
downloadable PDF on the site [2]. It is a piece of generative art:
Each download is different. (well, almost)

[1] e.g. http://ecx.images-amazon.com/images/I/518K467492L._SS500_.jpg
[2] http://lac.linuxaudio.org/?page_id=11

Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Linux Audio Conference 2008: Registration now open

[Michal Seta]

I will be there with Andrée Préfontaine as well.

See you there.

./MiS

On Jan 29, 2008 11:10 AM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:
>
> Miller is giving a keynote, so it seems it could be the Pd year at
> LAC.  I'll be presenting the NY Times project that I recently worked
> on.  Who else will be there?
>
> .hc
>
>
> On Jan 29, 2008, at 6:33 AM, LAC2008 wrote:
>
> > Dear all,
> >
> > The Linux Audio Conference 2008 in Cologne (Feb 28th - Mar 2nd 2008)
> > is just one month away now. The programme is shaping up, concerts are
> > being organized and coffee is about to be ordered.
> >
> > To help us with planning the LAC2008 we kindly ask you to register now
> > at the conference website. This helps us to estimate how many visitors
> > we may expect, what individuals the audience is made of, and allows to
> > produce name tags for all attendees so that it becomes easier to
> > identify each other.
> >
> > To register, please use the "Registration" form at
> > http://lac.linuxaudio.org
> >
> > Also we now have put accommodation info plus some maps of the
> > conference location online. You can find these on
> > http://lac.linuxaudio.org under "Visitor Info".
> >
> > Finally if you're living in Cologne or nearby: We are looking for
> > volunteers who would like to help out in any way, e.g. to host artists
> > and paper presenters in their flat. If you want to offer your help,
> > please contact the LAC2008 orga team at [EMAIL PROTECTED]
> >
> > The LAC2008 chair is looking forward to have another great conference
> > with you all.
> >
> > All the best
> > --
> >  Frank Barknecht and Martin Rumori
> >  Chairs of LAC2008
> >
> > ___
> > PD-announce mailing list
> > [EMAIL PROTECTED]
> > http://lists.puredata.info/listinfo/pd-announce
> >
> > ___
> > PD-list@iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> > listinfo/pd-list
>
>
>
> 
> 
>
> Man has survived hitherto because he was too ignorant to know how to
> realize his wishes.  Now that he can realize them, he must either
> change them, or perish.-William Carlos Williams
>
>
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



-- 
./MiS
514-344-0726
http://www.creazone.ca

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] vline~ question

[Kyle Klipowicz]

Haha this conversation is hilarious! Thanks for keeping it so lively everyone.

I may be suffering from Csound-itis. I want vline~ to basically act
like the linseg Csound opcode:

kr  linseg ia, idur1, ib[, idur2, ic[...]]

Where each segment is defined as points in time connected by a linear
ramp. It seems easier to me mostly because it's the first programmable
linear envelope generator that I was exposed to.

Perhaps just making a [linseg~] abstraction out of vline~ using the
previous suggestions on this thread would suffice. I definitely do not
want to limit the sustain possibilities of vline~ as a sort of ADSR
envelope generator. I just want to do what Steffen said. After all
this banter, it's probably easier for me to just remember what the
third tuple is in the comma separated messages.

However, I don't think it's possible to make a playable ADSR generator
with vline~ using only one message anyway. I think that it would still
have to be somewhat hacked together using some triggers and delays etc
like the ADSR example that Miller included with Pd. Am I wrong here?

Thanks again for participating in the thread!

~Kyle

On Jan 29, 2008 2:13 AM, IOhannes m zmoelnig <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Quoting Steffen Juul <[EMAIL PROTECTED]>:
> >
> >>> i cannot follow you here at all.
> >> Kyle wants to, correct me if i'm wrong, translate
> >
> > seems like i talked babylonian here.
> > i understood what kyle requested it, but i did not understand why he
> > wanted it.
>
> too early in the morning:
> i understood _what_ kyle requested, i did not understand _why_ he
> requested it.
>
>
> fgmasdr.
> IOhannes
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



-- 
-

 -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] vline~ question

[Roman Haefeli]

On Tue, 2008-01-29 at 14:55 -0600, Kyle Klipowicz wrote:
> However, I don't think it's possible to make a playable ADSR generator
> with vline~ using only one message anyway. I think that it would still
> have to be somewhat hacked together using some triggers and delays etc
> like the ADSR example that Miller included with Pd. Am I wrong here?

hm.. depends on how strictly you define 'one message'. yeah, it is
perfectly possible to make a [vline~] based ADSR generator without using
[del] and [list split] trickery and by using only one message box, but
you are right: in this message box you need several comma separated
messages (so: it's not possible with literally 1 message). usually you
don't know the length of the key pressure in advance, but for
simplicity's and illustration's sake let's assume we know it (T=280ms)
beforehand:


/\
   /  \_
  / \
 /   \
/ \

A=50ms S=0.6R=30ms 
 D=20ms   

|<- T=280ms   ->|


[0, 1 A, S D A, 0 R T(

which is:

[0, 1 50, 0.6 20 50, 0 30 280( <- one message box, four messsages
|
[vline~]

or you could replace the variables actually represented as letters by
real pd variables (A->$1, D->$2) and you would get a real adjustable
ADSR envelope generator with subsample accuracy ;-)

roman






 




___ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: 
http://mail.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] vline~ question

[Frank Barknecht]

Hallo,
Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:

> Haha this conversation is hilarious! Thanks for keeping it so lively everyone.
> 
> I may be suffering from Csound-itis. I want vline~ to basically act
> like the linseg Csound opcode:
> 
> kr  linseg ia, idur1, ib[, idur2, ic[...]]
> 
> Where each segment is defined as points in time connected by a linear
> ramp. It seems easier to me mostly because it's the first programmable
> linear envelope generator that I was exposed to.
> 
> Perhaps just making a [linseg~] abstraction out of vline~ using the
> previous suggestions on this thread would suffice.  

Basically all you need to do is add up all previous segment lengths to
get the delay for the next segment. Like attached (for a start). Note
that while in Csound, the duration comes before the target, the
attachement still has the duration after the target, in sync with
line~ and vline~.

Ciao
-- 
 Frank Barknecht _ __footils.org__


vlineseg~.pd
Description: application/puredata
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] vline~ question

[Diego Azar]

Hi, some years ago I made an abstraction that is only
a line~ type envelope but you can send it an infinite
message. Perhaps it is usefull for someone else.

Diego


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

dlineExample.pd
Description: 451365427-dlineExample.pd
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[Chris McCormick]

On Tue, Jan 29, 2008 at 10:41:39AM +0100, IOhannes m zmoelnig wrote:
> Chris McCormick wrote:
> >Interpereted works are
> >not covered by the GPL, but linked code is.
> 
> i cannot believe this.
> one of the gpl-faqs at fsf [1] is "If a programming language interpreter 
> has a license that is incompatible with the GPL, can I run GPL-covered 
> programs on it?"
> for me this (the mere existence of this faq with a different answer than 
> "programs written in interpreted languages are not covered by the GPL") 
> means, that programs running on an interpreter (that is: programs 
> written in interpreted languages) _can_ be covered by GPL.

Yes, I spoke too curtly. The first line of that answer says "When the
interpreter just interprets a language, the answer is no. The interpreted
program, to the interpreter, is just data; a free software license
like the GPL, based on copyright law, cannot limit what data you use
the interpreter on. You can run it on any data (interpreted program),
any way you like, and there are no requirements about licensing that
data to anyone."

To my mind, this is the important bit for Pd. It doesn't matter what you
link the Pd binary with - it is interpereting patches and they themselves
aren't linked to GPL code (in my mind anyway).

I guess you could argue that instantiating a GPL external in Pd is like
the case of Python's ctypes module, where you actually dynamically load a
library and expose the API to your interpereted code itself - calling
functions within the library from your script. I believe this requires
you to release your interpereted code under the GPL if the library you
are dynamically loading and linking your code with is GPL. But in my
mind, a GPL external is more linked into Pd itself, which then uses
that linked library to help interperet the Pd patch. So, in short, I
dunno 100%. I would be more likely to err on the side of saying that
you don't have to release your Pd patch GPL just because it uses GPL
externals. That seems like a really weird restriction to me, but I might
be wrong.

> >>finally, i am still unsure about the "static linking" clause, and how it 
> >>affects an interpreted language.
> >
> >It doesn't in the case of the GPL.
> 
> 
> again quoting from [1]:
> 
> > Another similar and very common case is to provide libraries with the
> > interpreter which are themselves interpreted. For instance, Perl comes
> > with many Perl modules, and a Java implementation comes with many Java
> > classes. These libraries and the programs that call them are always
> > dynamically linked together.
> >
> > A consequence is that if you choose to use GPL'd Perl modules or Java
> > classes in your program, you must release the program in a
> > GPL-compatible way, regardless of the license used in the Perl or Java
> > interpreter that the combined Perl or Java program will run on.
> 
> even though it does not mention Pd explicitely (probably because it is 
> significantly less used than e.g. Perl), it clearly states that if 
> "interpreted libraries" (perl modules, java classes, pd abstractions) 
> published under GPL (again: how is this possible if the GPL is not valid 
> for interpreted languages) are used, then your program (patch) must be 
> "released in a GPL-compatible way".

Yep, completely correct. So what it's basically saying is that if you
use a GPL abstraction in your patch, then your patch must be GPL. That
makes perfect sense to me. It doesn't say anything about externals
though, and the question there is more complicated because the external
is actually linked with the Pd interpereter itself, not with your patch
(or is it?). I still don't think it's required that you release patches
GPL just because you use a GPL external.

> >>i guess, if you have a  patch that depends on a GPL'ed pdlib, and you 
> >>are distributing your patch with this library (e.g. for convencience 
> >>reasons), then you are kind of _statically linking_ and thus your patch 
> >>is automatically GPL'ed too.
> >
> >I really don't think so, unless you are actually using a linker program
> >to link the .pd file with the Pd binary, which is very unlikely. If I am
> >wrong then ALL YOUR BASE BELONG TO MILLER and I am switching to
> >supercollider. :)
> 
> since when does statically linking defines ownership?
> how is the license of supercollider (GPL) different from Pd's license 
> (BSD), that it would prevent all of your sc code belong to james mccartney?

Of course statically linking doesn't define ownership. I like to think
that what I said was funny and would be considered as a joke, but that
is probably quite a stretch and I should go back to comedy school. Sorry
for confusing the issue!

Best,

Chris.

---
http://mccormick.cx

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] plugin~ problems (ladspa-linux) - strange behavior

[glerm soares]

2008/1/29, Jerome Tuncer <[EMAIL PROTECTED]>:
>
> Hi glerm,
>
> This has already been discussed a a few times I think. It happened to me
> as well, the workaround I found at the time was to start pd with the
> "unset LANG" prepended i.e. :
>
> $ unset LANG
> $ ./pd



Thanx a lot  Jerome!
It worked. :D

But I still wonder: why this "bug" happens? Can I call this a "bug" or is it
my system's fault? :)

cheers

glerm
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] fun with telephone sounds

[Hans-Christoph Steiner]

For some reason, I just reproduced some standard telephone sounds in  
Pd...  maybe these exist somewhere already, but I thought I'd post  
this for fun.




dialtones.pd
Description: Binary data



.hc


 



As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously. - Benjamin Franklin



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fun with telephone sounds

[Andy Farnell]

On Tue, 29 Jan 2008 21:25:35 -0500
Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote:

> 
> For some reason, I just reproduced some standard telephone sounds in  
> Pd...  maybe these exist somewhere already, but I thought I'd post  
> this for fun.
> 
> 

Hehe, nice.  I think DTMFs have been on my site for a long while,
but last year I did this as a demo of sending them over a noisy
line and decoding them - a complete toy phone system with dial
tones etc.


-- 
Use the source


phonefun.tar.gz
Description: Binary data
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] reverb for each grain

[punchik punchik]

hello, im working on a 64 voice granular synthesis
tool.   

i want to apply a reverb effect   to each grain independently. 

which is the best way of doing this?
which reverb do you recomend me to use? i was trying
freeverb but it consumes too much cpu. and 64
freeverbs makes my computer go slow.

and which is the best way to achieve this in terms of
cpu consumption?
is it better to have 64 abstraccions, or 64
subpatches?


thanks


p.




  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] reverb for each grain

[hard off]

64 seperate reverbs is gonna be hard for any cpu, regardless of which
reverb algorithm is used.

may i suggest that an alternative is to send your grains through the
same reverb, but to alter the amount of each grain that gets sent into
the reverb.  so, for example, grain 0 is sent 100% to the reverb,
grain 1 is sent 90% to the reverb, and 10% is passed on dry, grain 3
is sent 10% to the reverb and 90% is passed on dryetc

if think of reverb as the sound of a room, then the mix % is the
position of the object in the room.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] gpl vs creative commons

[marius schebella]

at the moment the discussion is theoretical because it is not possible 
to close-source a pd patch.

the original question (whether a pd patch is a piece of software or a 
piece of artwork - gpl/bsd vs cc) was not really answered.

and then - what about abstractions? under which license are for example 
the pdmtl abstractions released?

the big overall question is how to deal with intellectual property. do 
we as a society/community want to protect it? of course everybody likes 
sharing, but I don't think communism worked out well after all.

marius.


Chris McCormick wrote:
> On Tue, Jan 29, 2008 at 10:41:39AM +0100, IOhannes m zmoelnig wrote:
>> Chris McCormick wrote:
>>> Interpereted works are
>>> not covered by the GPL, but linked code is.
>> i cannot believe this.
>> one of the gpl-faqs at fsf [1] is "If a programming language interpreter 
>> has a license that is incompatible with the GPL, can I run GPL-covered 
>> programs on it?"
>> for me this (the mere existence of this faq with a different answer than 
>> "programs written in interpreted languages are not covered by the GPL") 
>> means, that programs running on an interpreter (that is: programs 
>> written in interpreted languages) _can_ be covered by GPL.
> 
> Yes, I spoke too curtly. The first line of that answer says "When the
> interpreter just interprets a language, the answer is no. The interpreted
> program, to the interpreter, is just data; a free software license
> like the GPL, based on copyright law, cannot limit what data you use
> the interpreter on. You can run it on any data (interpreted program),
> any way you like, and there are no requirements about licensing that
> data to anyone."
> 
> To my mind, this is the important bit for Pd. It doesn't matter what you
> link the Pd binary with - it is interpereting patches and they themselves
> aren't linked to GPL code (in my mind anyway).
> 
> I guess you could argue that instantiating a GPL external in Pd is like
> the case of Python's ctypes module, where you actually dynamically load a
> library and expose the API to your interpereted code itself - calling
> functions within the library from your script. I believe this requires
> you to release your interpereted code under the GPL if the library you
> are dynamically loading and linking your code with is GPL. But in my
> mind, a GPL external is more linked into Pd itself, which then uses
> that linked library to help interperet the Pd patch. So, in short, I
> dunno 100%. I would be more likely to err on the side of saying that
> you don't have to release your Pd patch GPL just because it uses GPL
> externals. That seems like a really weird restriction to me, but I might
> be wrong.
> 
 finally, i am still unsure about the "static linking" clause, and how it 
 affects an interpreted language.
>>> It doesn't in the case of the GPL.
>>
>> again quoting from [1]:
>>
>>> Another similar and very common case is to provide libraries with the
>>> interpreter which are themselves interpreted. For instance, Perl comes
>>> with many Perl modules, and a Java implementation comes with many Java
>>> classes. These libraries and the programs that call them are always
>>> dynamically linked together.
>>>
>>> A consequence is that if you choose to use GPL'd Perl modules or Java
>>> classes in your program, you must release the program in a
>>> GPL-compatible way, regardless of the license used in the Perl or Java
>>> interpreter that the combined Perl or Java program will run on.
>> even though it does not mention Pd explicitely (probably because it is 
>> significantly less used than e.g. Perl), it clearly states that if 
>> "interpreted libraries" (perl modules, java classes, pd abstractions) 
>> published under GPL (again: how is this possible if the GPL is not valid 
>> for interpreted languages) are used, then your program (patch) must be 
>> "released in a GPL-compatible way".
> 
> Yep, completely correct. So what it's basically saying is that if you
> use a GPL abstraction in your patch, then your patch must be GPL. That
> makes perfect sense to me. It doesn't say anything about externals
> though, and the question there is more complicated because the external
> is actually linked with the Pd interpereter itself, not with your patch
> (or is it?). I still don't think it's required that you release patches
> GPL just because you use a GPL external.
> 
 i guess, if you have a  patch that depends on a GPL'ed pdlib, and you 
 are distributing your patch with this library (e.g. for convencience 
 reasons), then you are kind of _statically linking_ and thus your patch 
 is automatically GPL'ed too.
>>> I really don't think so, unless you are actually using a linker program
>>> to link the .pd file with the Pd binary, which is very unlikely. If I am
>>> wrong then ALL YOUR BASE BELONG TO MILLER and I am switching to
>>> supercollider. :)
>> since when does statically linking defines ownership?
>> how is the license of super

Re: [PD] reverb for each grain

[punchik punchik]

thanks, but the idea is that each grain can have 
diferent reverb paramaters.  using one reverb doent
make to much sense to me... 

--- hard off <[EMAIL PROTECTED]> wrote:

> 64 seperate reverbs is gonna be hard for any cpu,
> regardless of which
> reverb algorithm is used.
> 
> may i suggest that an alternative is to send your
> grains through the
> same reverb, but to alter the amount of each grain
> that gets sent into
> the reverb.  so, for example, grain 0 is sent 100%
> to the reverb,
> grain 1 is sent 90% to the reverb, and 10% is passed
> on dry, grain 3
> is sent 10% to the reverb and 90% is passed on
> dryetc
> 
> if think of reverb as the sound of a room, then the
> mix % is the
> position of the object in the room.
> 



  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] reverb for each grain

[Charles Henry]

It is an interesting idea...
and 64 reverbs is too many, no matter how you do it.  Derek's idea is great!
I would just add to it, that you could use just a few voices to cover
the range of different settings of re-verbs and pan the grains between
the voices (effectively a linear interpolation between reverb effects)
to give each grain an unique reverb sound.

On Jan 29, 2008 10:00 PM, hard off <[EMAIL PROTECTED]> wrote:
> 64 seperate reverbs is gonna be hard for any cpu, regardless of which
> reverb algorithm is used.
>
> may i suggest that an alternative is to send your grains through the
> same reverb, but to alter the amount of each grain that gets sent into
> the reverb.  so, for example, grain 0 is sent 100% to the reverb,
> grain 1 is sent 90% to the reverb, and 10% is passed on dry, grain 3
> is sent 10% to the reverb and 90% is passed on dryetc
>
> if think of reverb as the sound of a room, then the mix % is the
> position of the object in the room.
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] reverb for each grain

[hard off]

well, as charles suggested, set up a few different reverbs of varying
decay lengths, and send varying percentages of each grain to the
different reverbs.

also, reverb usually has a 'dampening' setting, which will dull the
signal as it goes through, so another thing you can try is to mix in a
lowpass or bandpass filter after every voice before it goes in to the
reverb.  if you alter the dry/wet ratio of each voice going into the
filter, as well as altering the cutoff and q values for each filter it
will make it sound similar to if each voice were going through a
different reverb.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] reverb for each grain

[Kevin McCoy]

Not to mention, I hope you'll be showin' some clips of whatever you
come up with... doing something like this is something I have had in
mind for a while and I would love to hear the results you get!  Are
you thinking it can make the grain cloud more "dimensional" this way?
That was the idea I had..

km

On Jan 30, 2008 1:06 AM, hard off <[EMAIL PROTECTED]> wrote:
> well, as charles suggested, set up a few different reverbs of varying
> decay lengths, and send varying percentages of each grain to the
> different reverbs.
>
> also, reverb usually has a 'dampening' setting, which will dull the
> signal as it goes through, so another thing you can try is to mix in a
> lowpass or bandpass filter after every voice before it goes in to the
> reverb.  if you alter the dry/wet ratio of each voice going into the
> filter, as well as altering the cutoff and q values for each filter it
> will make it sound similar to if each voice were going through a
> different reverb.
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



-- 


http://art.sewanee.edu/mccoy

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list