Is attached.

uh.. isnt the dconv+partitioned convole patented?  i didnt put in any 
direct conv in the pconvolve opcode for that reason...

-=m

On Fri, 18 Mar 2005, Istvan Varga wrote:

> Is attached.
>
Ë
™
Ë
™

Matt J. Ingalls wrote:

> uh.. isnt the dconv+partitioned convole patented?  i didnt put in any 
> direct conv in the pconvolve opcode for that reason...

I deleted the opcode. I do think that people who patent such
trivial algorithms should be shot, but it is my own personal
opinion.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Matt J. Ingalls wrote:

> uh.. isnt the dconv+partitioned convole patented?  i didnt put in any 
> direct conv in the pconvolve opcode for that reason...

And what if I remove the dconv part, but keep the exponential
partitioning ? That would actually make the opcode better for
reverbs, as a reverb IR normally has leading silence, which
means that the direct convolution is only wasting CPU cycles.
Is the exponential partitioning on its own also patented ?


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Is the patent *international*? Is it possible to put the code on line 
somewhere where the patent does not hold and let us uh, be horrible 
criminals on our own?

Iain

Istvan Varga wrote:
> Matt J. Ingalls wrote:
> 
>> uh.. isnt the dconv+partitioned convole patented?  i didnt put in any 
>> direct conv in the pconvolve opcode for that reason...
> 
> 
> And what if I remove the dconv part, but keep the exponential
> partitioning ? That would actually make the opcode better for
> reverbs, as a reverb IR normally has leading silence, which
> means that the direct convolution is only wasting CPU cycles.
> Is the exponential partitioning on its own also patented ?
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, since we have the benefit of loadable libraries, someone can
maintain it separately and take responsibility for it, should they
want.

Istvan: Should I remove the gen52 manual entry as well, or does it
have use besides with ftconv?  Should gen52 be packaged with ftconv as
a loadable fgen (and thus removed from cs5)?

steven




On Fri, 18 Mar 2005 13:34:08 -0800, Iain Duncan  wrote:
> Is the patent *international*? Is it possible to put the code on line
> somewhere where the patent does not hold and let us uh, be horrible
> criminals on our own?
> 
> Iain
> 
> Istvan Varga wrote:
> > Matt J. Ingalls wrote:
> >
> >> uh.. isnt the dconv+partitioned convole patented?  i didnt put in any
> >> direct conv in the pconvolve opcode for that reason...
> >
> >
> > And what if I remove the dconv part, but keep the exponential
> > partitioning ? That would actually make the opcode better for
> > reverbs, as a reverb IR normally has leading silence, which
> > means that the direct convolution is only wasting CPU cycles.
> > Is the exponential partitioning on its own also patented ?
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Steven Yi wrote:

> Istvan: Should I remove the gen52 manual entry as well, or does it
> have use besides with ftconv?  Should gen52 be packaged with ftconv as
> a loadable fgen (and thus removed from cs5)?

GEN52 may still be useful even without ftconv. Furthermore, if the
patent problem is solved by removing the direct convolution part,
then ftconv can remain in the sources, and is still a very good
low latency convolution opcode. It just cannot reach a zero delay.
However, the manual is now outdated due to the changes.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Okay, I'll update the gen52 entry when I receive more information.


On Fri, 18 Mar 2005 22:47:38 +0100, Istvan Varga  wrote:
> Steven Yi wrote:
> 
> > Istvan: Should I remove the gen52 manual entry as well, or does it
> > have use besides with ftconv?  Should gen52 be packaged with ftconv as
> > a loadable fgen (and thus removed from cs5)?
> 
> GEN52 may still be useful even without ftconv. Furthermore, if the
> patent problem is solved by removing the direct convolution part,
> then ftconv can remain in the sources, and is still a very good
> low latency convolution opcode. It just cannot reach a zero delay.
> However, the manual is now outdated due to the changes.
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

i agree with you, and even would say to go ahead and leave your opcode 
in and wait
till Lake [or microsoft also has something, i think? ] finds out and 
starts complaining...
but i know other code has been held back due to patent issues so i 
thought i would
mention this.   plus i know the Anders Torger who makes bruteFIR got 
hassled
by lake or someone [  google 'bruteFIR patent' and youll see some 
patent #s and stuff]


but i am curious if you looked at the pconvovle opcode and if you did 
any comparisons
between equal-size partitions and increasing-exponential sizes?   if 
the exponential
way is better and not violation of patent maybe pconovle should use it?

-m

On Mar 18, 2005, at 8:33 AM, Istvan Varga wrote:

> Matt J. Ingalls wrote:
>
>> uh.. isnt the dconv+partitioned convole patented?  i didnt put in any 
>> direct conv in the pconvolve opcode for that reason...
>
> I deleted the opcode. I do think that people who patent such
> trivial algorithms should be shot, but it is my own personal
> opinion.
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Matt Ingalls wrote:

> but i am curious if you looked at the pconvovle opcode and if you did 
> any comparisons between equal-size partitions and increasing-exponential
 > sizes? if the exponential way is better and not violation of patent maybe
 > pconovle should use it?

The exponential method scales much better with long impulse responses,
especially if you want reasonably low latency at the same time. It is
also simpler to implement because no delay lines are needed. It does
have one disadvantage, though: the CPU usage is not as evenly distributed.
The optimal solution is perhaphs to split exponentially, but have equal
sized partitions for the last few segments, e.g. for a total length of
65536 - 1024:
   1024, 2048, 4096, 8192, 16384, 16384, 16384

I am really confused about what is patented and what is not. The text
of the patent is very vague, and is ridiculously overcomplicated (as
it usually is with obvious patents, to make them look "innovative").
It apparently does cover the original algorithm of ftconv (which used
a combination of direct and FFT convolution), but I am not sure about
the new version of ftconv, pconvolve, or even just plain old convolve.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

im too lazy to look at the code, but i assume it uses fft routines in 
csound and cannot be in
a library?

-m

On Mar 18, 2005, at 1:42 PM, Steven Yi wrote:

> Well, since we have the benefit of loadable libraries, someone can
> maintain it separately and take responsibility for it, should they
> want.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

matt wrote:

> im too lazy to look at the code, but i assume it uses fft routines in 
> csound and cannot be in
> a library?

ftconv already is, and always was a plugin opcode. There are new FFT
functions in Csound5 that can be accessed through the API (for
example csound->RealFFT, csound->InverseRealFFT and others).
By the way, I am now experimenting with the linear (equal sized)
partitioning algorithm and it seems to be usable with some optimizations.
It can never have the same low latency as the exponential version,
though, and breaks compatibility with orchestra syntax again.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Matt,

It would be cool for you to have pconvolve and pconvolveX for the
increasing-exponential size convolution - or an optional argument to choose
one or the other method.

-dB

on 3/18/05 9:39 PM, Matt Ingalls at matt@sonomatics.com wrote:

> 
> i agree with you, and even would say to go ahead and leave your opcode
> in and wait
> till Lake [or microsoft also has something, i think? ] finds out and
> starts complaining...
> but i know other code has been held back due to patent issues so i
> thought i would
> mention this.   plus i know the Anders Torger who makes bruteFIR got
> hassled
> by lake or someone [  google 'bruteFIR patent' and youll see some
> patent #s and stuff]
> 
> 
> but i am curious if you looked at the pconvovle opcode and if you did
> any comparisons
> between equal-size partitions and increasing-exponential sizes?   if
> the exponential
> way is better and not violation of patent maybe pconovle should use it?
> 
> -m
> 
> On Mar 18, 2005, at 8:33 AM, Istvan Varga wrote:
> 
>> Matt J. Ingalls wrote:
>> 
>>> uh.. isnt the dconv+partitioned convole patented?  i didnt put in any
>>> direct conv in the pconvolve opcode for that reason...
>> 
>> I deleted the opcode. I do think that people who patent such
>> trivial algorithms should be shot, but it is my own personal
>> opinion.
>> 
>> 
>> 
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 

_______________________________________________________________________
 +  Dr. Richard Boulanger, Professor
 +  Music Synthesis Department, Berklee College of Music
 +  1140 Boylston Street  - Boston, MA  02215-3693
 +  Office Phone: (617) 747-2485   Office Fax: (617) 747-2564
 +  eMail: rboulanger@csounds.com  or  rboulanger@berklee.edu
 +  WebPage: http://csounds.com/boulanger/
________________________________________________________________________
 +  Almost Everything Csound @ http://csounds.com/
 +  The Csound Catalog with Audio @ http://csounds.com/catalog/
 +  The Csound Book @ http://csounds.com/book/
 +  The Csound Magazine @ http://csounds.com/ezine/
 +  CsoundForums @ http://csounds.com/phpBB2/
________________________________________________________________________



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net