Hi Julian,
Thank you for your report. I am not the expert, just one of the current maintainers if the cyclone set of objects. I think the object works, but maybe not as the Max object. If this is the case I will try to fix it.
Hello,
I am sorry to bother you but I have an important question about the buffir~ object. I hope you can help me with this. I am not too experiencd with PD but I try to make an Binaural-Renderer. I want to use the buffir~ object to convolve an IR to a signal. This works right now. But I want to change the IR used for convolving with the signal when the head orientation changes. I had a look at the MAX/MSP 5 documentation as I understand this object was taken from MAX where the buffir~ object can be told to change the buffer~ object by using the set message. I tried this in PD but nothing happens. Obviously the IR is not loaded as there is no signal passing through the buffir~ object when using $1 as the name of the table and send a message [set tablename] to input 1 (the signal input where the clear message can be applied). Is this function not implemented in the PD buffir~ object? Or is there something I do wrong?
Note '$1' is not literary part of the name, just a placeholder of the first element on the message (=list) you send to the object. If something is wrong here, the console should contain an error message. Also see the help on $-variables.
I would be verry happy if could help me with this question! If this is not implemented and can't be worked around do you have any ideas how to solve my problem? Thank you very much in advance!
The attached patch is an adaptation of the help-patch, including a second buffer to switch to. Yo need to open it and draw non-zero values to get a signal through. It looks like you also have to provide the offset and length arguments, as leaving them out results in zero - meaning no useful convolution takes place.
When I have time, I'll check the behaviour of the Max5 object. It might work better or more user friendly. But first on the planning are some weeks vacation :-).
Regards Julian Jochheim
Greetings,
Fred Jan
P.S. I added the pd-list in the reply, the main forum for issues like this one (http://lists.puredata.info/listinfo/pd-list).
hey, how is going with this object?
I just wanted to say it'd be really good if it was updated to max size of 4096, which is the current configuration since max 6
256 is just too little and made more sense back in the day of max 5
hopefully it's an easy update, what do you say?
cheers
2015-08-01 15:18 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Julian,
Thank you for your report. I am not the expert, just one of the current maintainers if the cyclone set of objects. I think the object works, but maybe not as the Max object. If this is the case I will try to fix it.
Hello,
I am sorry to bother you but I have an important question about the buffir~ object. I hope you can help me with this. I am not too experiencd with PD but I try to make an Binaural-Renderer. I want to use the buffir~ object to convolve an IR to a signal. This works right now. But I want to change the IR used for convolving with the signal when the head orientation changes. I had a look at the MAX/MSP 5 documentation as I understand this object was taken from MAX where the buffir~ object can be told to change the buffer~ object by using the set message. I tried this in PD but nothing happens. Obviously the IR is not loaded as there is no signal passing through the buffir~ object when using $1 as the name of the table and send a message [set tablename] to input 1 (the signal input where the clear message can be applied). Is this function not implemented in the PD buffir~ object? Or is there something I do
wrong?
Note '$1' is not literary part of the name, just a placeholder of the first element on the message (=list) you send to the object. If something is wrong here, the console should contain an error message. Also see the help on $-variables.
I would be verry happy if could help me with this question! If this is not implemented and can't be worked around do you have any ideas how to solve my problem? Thank you very much in advance!
The attached patch is an adaptation of the help-patch, including a second buffer to switch to. Yo need to open it and draw non-zero values to get a signal through. It looks like you also have to provide the offset and length arguments, as leaving them out results in zero - meaning no useful convolution takes place.
When I have time, I'll check the behaviour of the Max5 object. It might work better or more user friendly. But first on the planning are some weeks vacation :-).
Regards Julian Jochheim
Greetings,
Fred Jan
P.S. I added the pd-list in the reply, the main forum for issues like this one (http://lists.puredata.info/listinfo/pd-list).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
hey, how is going with this object?
Not much, I just returned from vacation ;-).
I just wanted to say it'd be really good if it was updated to max size of 4096, which is the current configuration since max 6
256 is just too little and made more sense back in the day of max 5
hopefully it's an easy update, what do you say?
A first glance it doesn't look too complicated, but I think it would be good to retain the current buffer size as default, and add the larger size as an extra argument or message. Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option.
There are no other serious issues with buffir~?
cheers
Greetings,
Fred Jan
2015-08-01 15:18 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Julian, Thank you for your report. I am not the expert, just one of the current maintainers if the cyclone set of objects. I think the object works, but maybe not as the Max object. If this is the case I will try to fix it. > Hello, > > I am sorry to bother you but I have an important question about the > buffir~ object. > I hope you can help me with this. I am not too experiencd with PD but I > try to make > an Binaural-Renderer. I want to use the buffir~ object to convolve an IR > to a signal. > This works right now. But I want to change the IR used for convolving > with the signal > when the head orientation changes. I had a look at the MAX/MSP 5 > documentation > as I understand this object was taken from MAX where the buffir~ object > can be told > to change the buffer~ object by using the set message. I tried this in > PD but nothing > happens. Obviously the IR is not loaded as there is no signal passing > through the > buffir~ object when using $1 as the name of the table and send a message > [set tablename] > to input 1 (the signal input where the clear message can be applied). Is > this function > not implemented in the PD buffir~ object? Or is there something I do wrong? Note '$1' is not literary part of the name, just a placeholder of the first element on the message (=list) you send to the object. If something is wrong here, the console should contain an error message. Also see the help on $-variables. > > I would be verry happy if could help me with this question! If this is > not implemented > and can't be worked around do you have any ideas how to solve my problem? > Thank you very much in advance! The attached patch is an adaptation of the help-patch, including a second buffer to switch to. Yo need to open it and draw non-zero values to get a signal through. It looks like you also have to provide the offset and length arguments, as leaving them out results in zero - meaning no useful convolution takes place. When I have time, I'll check the behaviour of the Max5 object. It might work better or more user friendly. But first on the planning are some weeks vacation :-). > > Regards Julian Jochheim > Greetings, Fred Jan P.S. I added the pd-list in the reply, the main forum for issues like this one (http://lists.puredata.info/listinfo/pd-list). _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Howdy, hope you had a nice vacation buddy ;)
There are no other serious issues with buffir~?
haven't really played with it extensively, did try i t a bit and seemed alright.
A first glance it doesn't look too complicated, but I think it would be good to retain the current buffer size as default, and add the larger size as an extra argument or message.
I wonder why, since you already specify the table size in the object as arguments. Doesn't make much sense to me adding up another argument if I'm using a larger IR table. I guess the only difference would to change the help file and say "max size is 4096" instead of "256".
Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option.
Why would it be easier? It wouldn't conflict. Once you had a newer version working, that's it, no hard and no harm done.
Maybe that concern seems like making a big effort to not expand the buffir~ object, which I fail to see why. If you have a working version that allows bigger tables, there's no compatibility issues or anything, you're just able to get more out of it. So what would the concern be?
But I also have to say that there already exists an external that allows up to 4096 table sizes, that's [FIR~], from iemlib. So we wouldn't really have to do that at all... And, yeah, I knew about [FIR~] before, my request wasn't towards the necessity of a better and unavailable external object that'd do that, it was just a concern to make [buffir~] in cyclone as useful as I think it should be (let me stress and state that I believe 256 is really too tiny and restricting).
With the situation now that the development of extended ceased, and with the great work you've been doing taking care of cyclone (and also making it easily available into the deken plugin), I think all the objects in cyclone need attention, even if there are alternatives to it. The way I see [buffir~] now is that it is not useful, and that I'd rather use [FIR~] instead. But I wish I could rely on cyclone for it without needing to install a whole other library looking for alternatives of features that an object from cyclone should have.
I just think that if it isn't hard to expand it, and if it'd be working after that, then no more worries :)
what do you say?
who else would be with me ;) ?
cheers
2015-08-29 10:54 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
hey, how is going with this object?
Not much, I just returned from vacation ;-).
I just wanted to say it'd be really good if it was updated to max size of 4096, which is the current configuration since max 6
256 is just too little and made more sense back in the day of max 5
hopefully it's an easy update, what do you say?
A first glance it doesn't look too complicated, but I think it would be good to retain the current buffer size as default, and add the larger size as an extra argument or message. Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option.
There are no other serious issues with buffir~?
cheers
Greetings,
Fred Jan
2015-08-01 15:18 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Julian, Thank you for your report. I am not the expert, just one of thecurrent
maintainers if the cyclone set of objects. I think the object works,but
maybe not as the Max object. If this is the case I will try to fixit.
> Hello, > > I am sorry to bother you but I have an important question about the > buffir~ object. > I hope you can help me with this. I am not too experiencd with PD but I > try to make > an Binaural-Renderer. I want to use the buffir~ object to convolve an IR > to a signal. > This works right now. But I want to change the IR used forconvolving
> with the signal > when the head orientation changes. I had a look at the MAX/MSP 5 > documentation > as I understand this object was taken from MAX where the buffir~ object > can be told > to change the buffer~ object by using the set message. I triedthis in
> PD but nothing > happens. Obviously the IR is not loaded as there is no signalpassing
> through the > buffir~ object when using $1 as the name of the table and send a message > [set tablename] > to input 1 (the signal input where the clear message can be applied). Is > this function > not implemented in the PD buffir~ object? Or is there something I do wrong? Note '$1' is not literary part of the name, just a placeholder of the first element on the message (=list) you send to the object. If something is wrong here, the console should contain an error message. Also see the help on $-variables. > > I would be verry happy if could help me with this question! Ifthis is
> not implemented > and can't be worked around do you have any ideas how to solve my problem? > Thank you very much in advance! The attached patch is an adaptation of the help-patch, including a second buffer to switch to. Yo need to open it and draw non-zerovalues
to get a signal through. It looks like you also have to provide the offset and length arguments, as leaving them out results in zero - meaning no useful convolution takes place. When I have time, I'll check the behaviour of the Max5 object. Itmight
work better or more user friendly. But first on the planning are some weeks vacation :-). > > Regards Julian Jochheim > Greetings, Fred Jan P.S. I added the pd-list in the reply, the main forum for issues like this one (http://lists.puredata.info/listinfo/pd-list). _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
On 2015-08-30 08:41 AM, Alexandre Torres Porres wrote:
Howdy, hope you had a nice vacation buddy ;)
Yes, thank you. It took some time to buffir~, but here we are :-).
There are no other serious issues with buffir~?
haven't really played with it extensively, did try i t a bit and seemed alright.
A first glance it doesn't look too complicated, but I think it would be good to retain the current buffer size as default, and add the larger size as an extra argument or message.
I wonder why, since you already specify the table size in the object as arguments. Doesn't make much sense to me adding up another argument if I'm using a larger IR table. I guess the only difference would to change the help file and say "max size is 4096" instead of "256".
The second argument is the number of samples to be used in the convolution, not the size of the buffer, which is external. The first argument is an offset in the used buffer.
Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option.
Why would it be easier? It wouldn't conflict. Once you had a newer version working, that's it, no hard and no harm done.
Maybe that concern seems like making a big effort to not expand the buffir~ object, which I fail to see why. If you have a working version that allows bigger tables, there's no compatibility issues or anything, you're just able to get more out of it. So what would the concern be?
But I also have to say that there already exists an external that allows up to 4096 table sizes, that's [FIR~], from iemlib. So we wouldn't really have to do that at all... And, yeah, I knew about [FIR~] before, my request wasn't towards the necessity of a better and unavailable external object that'd do that, it was just a concern to make [buffir~] in cyclone as useful as I think it should be (let me stress and state that I believe 256 is really too tiny and restricting).
Buffir~ uses convolution in the time-domain, meaning using much larger buffer sizes isn't interesting performance wise, the local expert told me. Better performance can be reached using frequency domain filtering. But from the educational point of view, it is better to let the user decide which method is best, and change the BUFFIR_MAXSIZE value.
Hopefully coming week, because after that, I'll be busy with work-related issues.
Greetings,
Fred Jan
With the situation now that the development of extended ceased, and with the great work you've been doing taking care of cyclone (and also making it easily available into the deken plugin), I think all the objects in cyclone need attention, even if there are alternatives to it. The way I see [buffir~] now is that it is not useful, and that I'd rather use [FIR~] instead. But I wish I could rely on cyclone for it without needing to install a whole other library looking for alternatives of features that an object from cyclone should have.
I just think that if it isn't hard to expand it, and if it'd be working after that, then no more worries :)
what do you say?
who else would be with me ;) ?
cheers
2015-08-29 10:54 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Alexandre, > hey, how is going with this object? Not much, I just returned from vacation ;-). > > I just wanted to say it'd be really good if it was updated to max size > of 4096, which is the current configuration since max 6 > > 256 is just too little and made more sense back in the day of max 5 > > hopefully it's an easy update, what do you say? A first glance it doesn't look too complicated, but I think it would be good to retain the current buffer size as default, and add the larger size as an extra argument or message. Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option. There are no other serious issues with buffir~? > > cheers Greetings, Fred Jan > > 2015-08-01 15:18 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> > <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>: > > Hi Julian, > > Thank you for your report. I am not the expert, just one of the current > maintainers if the cyclone set of objects. I think the object works, but > maybe not as the Max object. If this is the case I will try to fix it. > > > Hello, > > > > I am sorry to bother you but I have an important question about the > > buffir~ object. > > I hope you can help me with this. I am not too experiencd with PD > but I > > try to make > > an Binaural-Renderer. I want to use the buffir~ object to convolve > an IR > > to a signal. > > This works right now. But I want to change the IR used for convolving > > with the signal > > when the head orientation changes. I had a look at the MAX/MSP 5 > > documentation > > as I understand this object was taken from MAX where the buffir~ > object > > can be told > > to change the buffer~ object by using the set message. I tried this in > > PD but nothing > > happens. Obviously the IR is not loaded as there is no signal passing > > through the > > buffir~ object when using $1 as the name of the table and send a > message > > [set tablename] > > to input 1 (the signal input where the clear message can be > applied). Is > > this function > > not implemented in the PD buffir~ object? Or is there something I > do wrong? > > Note '$1' is not literary part of the name, just a placeholder of the > first element on the message (=list) you send to the object. If > something is wrong here, the console should contain an error message. > Also see the help on $-variables. > > > > I would be verry happy if could help me with this question! If this is > > not implemented > > and can't be worked around do you have any ideas how to solve my > problem? > > Thank you very much in advance! > > The attached patch is an adaptation of the help-patch, including a > second buffer to switch to. Yo need to open it and draw non-zero values > to get a signal through. It looks like you also have to provide the > offset and length arguments, as leaving them out results in zero - > meaning no useful convolution takes place. > > When I have time, I'll check the behaviour of the Max5 object. It might > work better or more user friendly. But first on the planning are some > weeks vacation :-). > > > > Regards Julian Jochheim > > > > Greetings, > > Fred Jan > > P.S. I added the pd-list in the reply, the main forum for issues like > this one (http://lists.puredata.info/listinfo/pd-list). > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
Hmm, so you say the object will compute the maximum table size no matter if we're using just, say, 128 samples? Even if the arraysize of the impulse response is just 128? As if it would always consume more CPU even with the same smaller impulses?
I wonder how things work internally with [FIR~].
It is true that convolution is quite expensive. In the frequency domain it is better, but it has it's own complications. The best solution is actually "partitioned convolution". In Pd we have [partconv~] for that, which has a couple of issues, but it is great. So you can use it for spending the same as a maximum of 256 buffer size for impulses that are 4096 or even greater.
Unfortunately, Max does not have a partitioned convolution object, I think that there had to be one... but whatever...
Anyway, I don't believe 4096 is such a costy even if doing this increases cmputation time. And we still have other options like [partconv~] and [FIR~] in Pd. But in practice I think we'll have [buffir~] as a better/more versatile object/option than [FIR~] in the end. So we have more to gain than lose with this.
Hopefully coming week, because after that, I'll be busy with work-related issues.
Thanks! So, I can see how maintaining this library is not an easy task. I care about it a lot, as I've been recently using it to teach Max, and now that extended reached a dead end I believe it's one of the main libraries to be taken seriously and expand Pd. So I'm trying to get a friend of mine onboard with this, he's a teacher at a university and might be able to have students helping in a project. His name is Flavio and he's copied here. We were talking about writing a project to get some support for this project.
I keep finding issues with objects as I try them, so I still think there might be a lot more to fix. I'm about to write another email on issues with [matrix~]. And I also think we could clone some more objects. Hopefully this happens and we'll have more support to take care of this library, huh?
cheers
2015-09-05 18:36 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
Hi Alexandre,
On 2015-08-30 08:41 AM, Alexandre Torres Porres wrote:
Howdy, hope you had a nice vacation buddy ;)
Yes, thank you. It took some time to buffir~, but here we are :-).
There are no other serious issues with buffir~?
haven't really played with it extensively, did try i t a bit and seemed alright.
A first glance it doesn't look too complicated, but I think it would be good to retain the current buffer size as default, and add the larger size as an extra argument or message.
I wonder why, since you already specify the table size in the object as arguments. Doesn't make much sense to me adding up another argument if I'm using a larger IR table. I guess the only difference would to change the help file and say "max size is 4096" instead of "256".
The second argument is the number of samples to be used in the convolution, not the size of the buffer, which is external. The first argument is an offset in the used buffer.
Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option.
Why would it be easier? It wouldn't conflict. Once you had a newer version working, that's it, no hard and no harm done.
Maybe that concern seems like making a big effort to not expand the buffir~ object, which I fail to see why. If you have a working version that allows bigger tables, there's no compatibility issues or anything, you're just able to get more out of it. So what would the concern be?
But I also have to say that there already exists an external that allows up to 4096 table sizes, that's [FIR~], from iemlib. So we wouldn't really have to do that at all... And, yeah, I knew about [FIR~] before, my request wasn't towards the necessity of a better and unavailable external object that'd do that, it was just a concern to make [buffir~] in cyclone as useful as I think it should be (let me stress and state that I believe 256 is really too tiny and restricting).
Buffir~ uses convolution in the time-domain, meaning using much larger buffer sizes isn't interesting performance wise, the local expert told me. Better performance can be reached using frequency domain filtering. But from the educational point of view, it is better to let the user decide which method is best, and change the BUFFIR_MAXSIZE value.
Hopefully coming week, because after that, I'll be busy with work-related issues.
Greetings,
Fred Jan
With the situation now that the development of extended ceased, and with the great work you've been doing taking care of cyclone (and also making it easily available into the deken plugin), I think all the objects in cyclone need attention, even if there are alternatives to it. The way I see [buffir~] now is that it is not useful, and that I'd rather use [FIR~] instead. But I wish I could rely on cyclone for it without needing to install a whole other library looking for alternatives of features that an object from cyclone should have.
I just think that if it isn't hard to expand it, and if it'd be working after that, then no more worries :)
what do you say?
who else would be with me ;) ?
cheers
2015-08-29 10:54 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Alexandre, > hey, how is going with this object? Not much, I just returned from vacation ;-). > > I just wanted to say it'd be really good if it was updated to maxsize
> of 4096, which is the current configuration since max 6 > > 256 is just too little and made more sense back in the day of max 5 > > hopefully it's an easy update, what do you say? A first glance it doesn't look too complicated, but I think it wouldbe
good to retain the current buffer size as default, and add the larger size as an extra argument or message. Maybe creating a separate object, like buffir4k~, somewhere outside cyclone would be the easier option. There are no other serious issues with buffir~? > > cheers Greetings, Fred Jan > > 2015-08-01 15:18 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>: > > Hi Julian, > > Thank you for your report. I am not the expert, just one of the current > maintainers if the cyclone set of objects. I think the object works, but > maybe not as the Max object. If this is the case I will try to fix it. > > > Hello, > > > > I am sorry to bother you but I have an important question about the > > buffir~ object. > > I hope you can help me with this. I am not too experiencd with PD > but I > > try to make > > an Binaural-Renderer. I want to use the buffir~ object to convolve > an IR > > to a signal. > > This works right now. But I want to change the IR used for convolving > > with the signal > > when the head orientation changes. I had a look at theMAX/MSP 5
> > documentation > > as I understand this object was taken from MAX where thebuffir~
> object > > can be told > > to change the buffer~ object by using the set message. I tried this in > > PD but nothing > > happens. Obviously the IR is not loaded as there is no signal passing > > through the > > buffir~ object when using $1 as the name of the table andsend a
> message > > [set tablename] > > to input 1 (the signal input where the clear message can be > applied). Is > > this function > > not implemented in the PD buffir~ object? Or is there something I > do wrong? > > Note '$1' is not literary part of the name, just a placeholder of the > first element on the message (=list) you send to the object. If > something is wrong here, the console should contain an error message. > Also see the help on $-variables. > > > > I would be verry happy if could help me with this question! If this is > > not implemented > > and can't be worked around do you have any ideas how tosolve my
> problem? > > Thank you very much in advance! > > The attached patch is an adaptation of the help-patch,including a
> second buffer to switch to. Yo need to open it and draw non-zero values > to get a signal through. It looks like you also have to provide the > offset and length arguments, as leaving them out results inzero -
> meaning no useful convolution takes place. > > When I have time, I'll check the behaviour of the Max5 object. It might > work better or more user friendly. But first on the planning are some > weeks vacation :-). > > > > Regards Julian Jochheim > > > > Greetings, > > Fred Jan > > P.S. I added the pd-list in the reply, the main forum for issues like > this one (http://lists.puredata.info/listinfo/pd-list). > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> mailinglist
> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >
On 09/05/2015 11:58 PM, Alexandre Torres Porres wrote:
Unfortunately, Max does not have a partitioned convolution object, I think that there had to be one... but whatever...
probably. but not our problem :-)
Anyway, I don't believe 4096 is such a costy even if doing this increases cmputation time. And we still have other options like [partconv~] and [FIR~] in Pd. But in practice I think we'll have [buffir~] as a better/more versatile object/option than [FIR~] in the end.
what makes it better/more versatile than [FIR~]?
fdmsr IOhannes
On 2015-09-06 03:55 PM, IOhannes m zmölnig wrote:
On 09/05/2015 11:58 PM, Alexandre Torres Porres wrote:
Anyway, I don't believe 4096 is such a costy even if doing this increases cmputation time. And we still have other options like [partconv~] and [FIR~] in Pd. But in practice I think we'll have [buffir~] as a better/more versatile object/option than [FIR~] in the end.
what makes it better/more versatile than [FIR~]?
[buffir~] has an offset argument/inlet which allows you to select an arbitrary startpoint within a buffer. You might have an array with multiple filter-kernels and use the offset to switch between those (just guessing here...).
[FIR~] seems to have some optimization which probably makes it more efficient.
fdmsr IOhannes
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
yeah, I was thinking about this versatility. I guess "better" isn't a good word. I was thinking "more powerful"
2015-09-06 17:24 GMT-03:00 Fred Jan Kraan fjkraan@xs4all.nl:
On 2015-09-06 03:55 PM, IOhannes m zmölnig wrote:
On 09/05/2015 11:58 PM, Alexandre Torres Porres wrote:
Anyway, I don't believe 4096 is such a costy even if doing this
increases
cmputation time. And we still have other options like [partconv~] and [FIR~] in Pd. But in practice I think we'll have [buffir~] as a
better/more
versatile object/option than [FIR~] in the end.
what makes it better/more versatile than [FIR~]?
[buffir~] has an offset argument/inlet which allows you to select an arbitrary startpoint within a buffer. You might have an array with multiple filter-kernels and use the offset to switch between those (just guessing here...).
[FIR~] seems to have some optimization which probably makes it more efficient.
fdmsr IOhannes
Greetings,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2015-09-06 23:58, Alexandre Torres Porres wrote:
yeah, I was thinking about this versatility. I guess "better" isn't a good word. I was thinking "more powerful"
afaict, i would say it has a single feature that is trivial to implement for [FIR~] as well...
and if the table data itself is static¹, then it should be pretty easy to get the desired behaviour with a wrapper abstraction around [FIR~] that copies the data with an offset into an internal proxy table.
but well, if this is the only feature that makes [Buffir~] more powerful than [FIR~], i will tell thomas to add it.
fgasdrm IOhannes
¹ that is: you don't continuously change the impulse response without telling the filter object
that's the only difference I can think of, but you can also just switch between tables, not sure how important this feature is, seems is just something for possible fun anyway. cheers
2015-09-07 4:52 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-09-06 23:58, Alexandre Torres Porres wrote:
yeah, I was thinking about this versatility. I guess "better" isn't a
good
word. I was thinking "more powerful"
afaict, i would say it has a single feature that is trivial to implement for [FIR~] as well...
and if the table data itself is static¹, then it should be pretty easy to get the desired behaviour with a wrapper abstraction around [FIR~] that copies the data with an offset into an internal proxy table.
but well, if this is the only feature that makes [Buffir~] more powerful than [FIR~], i will tell thomas to add it.
fgasdrm IOhannes
¹ that is: you don't continuously change the impulse response without telling the filter object
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Alexandre,
Hmm, so you say the object will compute the maximum table size no matter if we're using just, say, 128 samples? Even if the arraysize of the impulse response is just 128? As if it would always consume more CPU even with the same smaller impulses?
No, only the number of samples specified by the length argument or inlet is used. But as this is convolution, is is done for every sample in the frame. So convolving a frame with 64 samples with a 4096 sized buffer means 262144 calculations. In this case it is more efficient to translate the frame to the frequency domain, process there and translate it back.
I wonder how things work internally with [FIR~].
As far as I can see, it does something similar. It doesn't use the FFT route.
It is true that convolution is quite expensive. In the frequency domain it is better, but it has it's own complications. The best solution is actually "partitioned convolution". In Pd we have [partconv~] for that, which has a couple of issues, but it is great. So you can use it for spending the same as a maximum of 256 buffer size for impulses that are 4096 or even greater.
Unfortunately, Max does not have a partitioned convolution object, I think that there had to be one... but whatever...
Anyway, I don't believe 4096 is such a costy even if doing this increases cmputation time. And we still have other options like [partconv~] and [FIR~] in Pd. But in practice I think we'll have [buffir~] as a better/more versatile object/option than [FIR~] in the end. So we have more to gain than lose with this.
Well, when it becomes possible, you can check it. That is the educational aspect :-).
Hopefully coming week, because after that, I'll be busy with work-related issues.
Thanks! So, I can see how maintaining this library is not an easy task. I care about it a lot, as I've been recently using it to teach Max, and now that extended reached a dead end I believe it's one of the main libraries to be taken seriously and expand Pd. So I'm trying to get a friend of mine onboard with this, he's a teacher at a university and might be able to have students helping in a project. His name is Flavio and he's copied here. We were talking about writing a project to get some support for this project.
All help is welcome. Proper described and demonstrated issues with objects are half the work of fixing them. There are unit-test patches in the Pd-extended distribution which can be used for this.
I keep finding issues with objects as I try them, so I still think there might be a lot more to fix. I'm about to write another email on issues with [matrix~]. And I also think we could clone some more objects. Hopefully this happens and we'll have more support to take care of this library, huh?
I have no intention to stop supporting cyclone. But it can happen there are periods when time for it is limited.
cheers
Greetings,
Fred Jan
2015-09-05 18:36 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl mailto:fjkraan@xs4all.nl>:
Hi Alexandre, On 2015-08-30 08:41 AM, Alexandre Torres Porres wrote: > Howdy, hope you had a nice vacation buddy ;) Yes, thank you. It took some time to buffir~, but here we are :-). > >> There are no other serious issues with buffir~? > > haven't really played with it extensively, did try i t a bit and seemed > alright. > >> A first glance it doesn't look too complicated, but I think it would be >> good to retain the current buffer size as default, and add the larger >> size as an extra argument or message. > > I wonder why, since you already specify the table size in the object as > arguments. Doesn't make much sense to me adding up another argument if > I'm using a larger IR table. I guess the only difference would to change > the help file and say "max size is 4096" instead of "256". The second argument is the number of samples to be used in the convolution, not the size of the buffer, which is external. The first argument is an offset in the used buffer. > >> Maybe creating a separate object, like buffir4k~, somewhere >> outside cyclone would be the easier option. > > Why would it be easier? It wouldn't conflict. Once you had a newer > version working, that's it, no hard and no harm done. > > Maybe that concern seems like making a big effort to not expand the > buffir~ object, which I fail to see why. If you have a working version > that allows bigger tables, there's no compatibility issues or anything, > you're just able to get more out of it. So what would the concern be? > > But I also have to say that there already exists an external that allows > up to 4096 table sizes, that's [FIR~], from iemlib. So we wouldn't > really have to do that at all... And, yeah, I knew about [FIR~] before, > my request wasn't towards the necessity of a better and unavailable > external object that'd do that, it was just a concern to make [buffir~] > in cyclone as useful as I think it should be (let me stress and state > that I believe 256 is really too tiny and restricting). Buffir~ uses convolution in the time-domain, meaning using much larger buffer sizes isn't interesting performance wise, the local expert told me. Better performance can be reached using frequency domain filtering. But from the educational point of view, it is better to let the user decide which method is best, and change the BUFFIR_MAXSIZE value. Hopefully coming week, because after that, I'll be busy with work-related issues. Greetings, Fred Jan > > With the situation now that the development of extended ceased, and with > the great work you've been doing taking care of cyclone (and also making > it easily available into the deken plugin), I think all the objects in > cyclone need attention, even if there are alternatives to it. The way I > see [buffir~] now is that it is not useful, and that I'd rather use > [FIR~] instead. But I wish I could rely on cyclone for it without > needing to install a whole other library looking for alternatives of > features that an object from cyclone should have. > > I just think that if it isn't hard to expand it, and if it'd be working > after that, then no more worries :) > > what do you say? > > who else would be with me ;) ? > > cheers > > 2015-08-29 10:54 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> > <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>: > > Hi Alexandre, > > > hey, how is going with this object? > > Not much, I just returned from vacation ;-). > > > > I just wanted to say it'd be really good if it was updated to max size > > of 4096, which is the current configuration since max 6 > > > > 256 is just too little and made more sense back in the day of max 5 > > > > hopefully it's an easy update, what do you say? > > A first glance it doesn't look too complicated, but I think it would be > good to retain the current buffer size as default, and add the larger > size as an extra argument or message. > Maybe creating a separate object, like buffir4k~, somewhere outside > cyclone would be the easier option. > > There are no other serious issues with buffir~? > > > > cheers > > Greetings, > > Fred Jan > > > > 2015-08-01 15:18 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>> > > <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>>: > > > > Hi Julian, > > > > Thank you for your report. I am not the expert, just one of > the current > > maintainers if the cyclone set of objects. I think the object > works, but > > maybe not as the Max object. If this is the case I will try to > fix it. > > > > > Hello, > > > > > > I am sorry to bother you but I have an important question > about the > > > buffir~ object. > > > I hope you can help me with this. I am not too experiencd > with PD > > but I > > > try to make > > > an Binaural-Renderer. I want to use the buffir~ object to > convolve > > an IR > > > to a signal. > > > This works right now. But I want to change the IR used for > convolving > > > with the signal > > > when the head orientation changes. I had a look at the MAX/MSP 5 > > > documentation > > > as I understand this object was taken from MAX where the buffir~ > > object > > > can be told > > > to change the buffer~ object by using the set message. I > tried this in > > > PD but nothing > > > happens. Obviously the IR is not loaded as there is no > signal passing > > > through the > > > buffir~ object when using $1 as the name of the table and send a > > message > > > [set tablename] > > > to input 1 (the signal input where the clear message can be > > applied). Is > > > this function > > > not implemented in the PD buffir~ object? Or is there > something I > > do wrong? > > > > Note '$1' is not literary part of the name, just a placeholder > of the > > first element on the message (=list) you send to the object. If > > something is wrong here, the console should contain an error > message. > > Also see the help on $-variables. > > > > > > I would be verry happy if could help me with this question! > If this is > > > not implemented > > > and can't be worked around do you have any ideas how to solve my > > problem? > > > Thank you very much in advance! > > > > The attached patch is an adaptation of the help-patch, including a > > second buffer to switch to. Yo need to open it and draw > non-zero values > > to get a signal through. It looks like you also have to > provide the > > offset and length arguments, as leaving them out results in zero - > > meaning no useful convolution takes place. > > > > When I have time, I'll check the behaviour of the Max5 object. > It might > > work better or more user friendly. But first on the planning > are some > > weeks vacation :-). > > > > > > Regards Julian Jochheim > > > > > > > Greetings, > > > > Fred Jan > > > > P.S. I added the pd-list in the reply, the main forum for > issues like > > this one (http://lists.puredata.info/listinfo/pd-list). > > > > _______________________________________________ > > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>> > <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> <mailto:Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at>>> mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > > > > >
-
Alexandre Torres Porres -
Fred Jan Kraan -
IOhannes m zmoelnig -
IOhannes m zmölnig