I just wanted to ask this: would it be much better if they were
written in C, or would it make not much difference.?(performance-
wise)
Typically, an Ambisonic decoder accepts from N channels as input,
(where N is from 3 to about 7) and outputs a single channel. An
encoder accepts one input and has N output channels. (the other way
around) An object that would rotate a whole scene would accept N
channel.
You can probably sktech all the processes directly in pyo but I think it will significantly increases CPU usage... A single object written in C will be more effective. I can help you with the guidelines of the PyoObject design.
Are you comming to UdeM finally? I heard you've seen Jean recently...
> Hello! > I am considering porting my Ambisonic abstractions for Pure Data to > Pyo. > They are currently part of the rather deprecated PdMtlAbstractions:
> I just wanted to ask this: would it be much better if they were > written in C, or would it make not much difference.?(performance- > wise)
> Typically, an Ambisonic decoder accepts from N channels as input, > (where N is from 3 to about 7) and outputs a single channel. An > encoder accepts one input and has N output channels. (the other way > around) An object that would rotate a whole scene would accept N > channel.
> You can probably sktech all the processes directly in pyo but I think it > will significantly increases CPU usage... A single object written in C will > be more effective. > I can help you with the guidelines of the PyoObject design.
> Are you comming to UdeM finally? I heard you've seen Jean recently...
>> Hello! >> I am considering porting my Ambisonic abstractions for Pure Data to >> Pyo. >> They are currently part of the rather deprecated PdMtlAbstractions:
>> I just wanted to ask this: would it be much better if they were >> written in C, or would it make not much difference.?(performance- >> wise)
>> Typically, an Ambisonic decoder accepts from N channels as input, >> (where N is from 3 to about 7) and outputs a single channel. An >> encoder accepts one input and has N output channels. (the other way >> around) An object that would rotate a whole scene would accept N >> channel.
Well, we have to deal with the Python object structure but it's not very complicated. It's always in my plan to write a tutorial an a SDK with examples and an empty framework to start writing pyo objects. I'll have more time this summer, I'll be on it!
> Have you considered an easier sdk for pyo object creation? The process > is currently quite convoluted...
> Cheers, > Andres
> 2011/4/21 Olivier Bélanger <belan...@gmail.com>: > > Hi Alexandre,
> > You can probably sktech all the processes directly in pyo but I think it > > will significantly increases CPU usage... A single object written in C > will > > be more effective. > > I can help you with the guidelines of the PyoObject design.
> > Are you comming to UdeM finally? I heard you've seen Jean recently...
> >> Hello! > >> I am considering porting my Ambisonic abstractions for Pure Data to > >> Pyo. > >> They are currently part of the rather deprecated PdMtlAbstractions:
> >> I just wanted to ask this: would it be much better if they were > >> written in C, or would it make not much difference.?(performance- > >> wise)
> >> Typically, an Ambisonic decoder accepts from N channels as input, > >> (where N is from 3 to about 7) and outputs a single channel. An > >> encoder accepts one input and has N output channels. (the other way > >> around) An object that would rotate a whole scene would accept N > >> channel.
Le 21 avril 2011 10:45, Olivier Bélanger <belan...@gmail.com> a écrit :
> You can probably sktech all the processes directly in pyo but I think it > will significantly increases CPU usage... A single object written in C will > be more effective. > I can help you with the guidelines of the PyoObject design.
I'd be interested in doing it in C. I have good C and DSP skills, so it should be pretty fast. Would you like to meet for a beer or skotch? Otherwise, we can do this over email/chat/phone.
> Are you comming to UdeM finally? I heard you've seen Jean recently...
I will take a few more months to get my master thesis done, so I'm not going to join your research group next fall, unfortunately. Maybe in a year? We'll see.
Le 21 avril 2011 11:18, Olivier Bélanger <belan...@gmail.com> a écrit :
> Well, we have to deal with the Python object structure but it's not very > complicated. It's always in my plan to write a tutorial an a SDK with > examples and an empty framework to start writing pyo objects. I'll have more > time this summer, I'll be on it!
I can help with a quick tutorial if you help me a little. :)
> Le 21 avril 2011 10:45, Olivier Bélanger <belan...@gmail.com> a écrit : > > You can probably sktech all the processes directly in pyo but I think it > > will significantly increases CPU usage... A single object written in C > will > > be more effective. > > I can help you with the guidelines of the PyoObject design.
> I'd be interested in doing it in C. I have good C and DSP skills, so > it should be pretty fast. > Would you like to meet for a beer or skotch? Otherwise, we can do this > over email/chat/phone.
> > Are you comming to UdeM finally? I heard you've seen Jean recently...
> I will take a few more months to get my master thesis done, so I'm not > going to join your research group next fall, unfortunately. Maybe in a > year? We'll see.
