[PD] Pure Data Buffir~ object

Alexandre Torres Porres porres at gmail.com
Sun Aug 30 08:41:19 CEST 2015


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 at 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 at xs4all.nl
> > <mailto:fjkraan at 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 at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
> >     UNSUBSCRIBE and account-management ->
> >     http://lists.puredata.info/listinfo/pd-list
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150830/a18f242b/attachment-0001.html>


More information about the Pd-list mailing list