<div dir="ltr"><div>Howdy, hope you had a nice vacation buddy ;)</div><div><br></div>> <span style="font-size:12.8000001907349px">There are no other serious issues with buffir~?</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">haven't really played with it extensively, did try i t a bit and seemed alright.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">A first glance it doesn't look too complicated, but </span><span style="font-size:12.8000001907349px">I think it would be</span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">good to retain the current buffer</span><span style="font-size:12.8000001907349px"> size as default, and add the larger</span></div><span style="font-size:12.8000001907349px">> size as an extra argument or message.</span><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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".</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">Maybe creating a separate object, like buffir4k~, somewhere </span></div><div><span style="font-size:12.8000001907349px">> outside </span><span style="font-size:12.8000001907349px">cyclone would be the easier option.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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... </span><span style="font-size:12.8000001907349px">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).</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">With the situation now that the development of extended ceased, and w</span><span style="font-size:12.8000001907349px">ith 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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I just think that if it isn't hard to expand it, and if it'd be working after that, then no more worries :)</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">what do you say?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">who else would be with me ;) ? </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">cheers</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-29 10:54 GMT-03:00 Fred Jan Kraan <span dir="ltr"><<a href="mailto:fjkraan@xs4all.nl" target="_blank">fjkraan@xs4all.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alexandre,<br>
<span class=""><br>
> hey, how is going with this object?<br>
<br>
</span>Not much, I just returned from vacation ;-).<br>
<span class="">><br>
> I just wanted to say it'd be really good if it was updated to max size<br>
> of 4096, which is the current configuration since max 6<br>
><br>
> 256 is just too little and made more sense back in the day of max 5<br>
><br>
> hopefully it's an easy update, what do you say?<br>
<br>
</span>A first glance it doesn't look too complicated, but I think it would be<br>
good to retain the current buffer size as default, and add the larger<br>
size as an extra argument or message.<br>
Maybe creating a separate object, like buffir4k~, somewhere outside<br>
cyclone would be the easier option.<br>
<br>
There are no other serious issues with buffir~?<br>
><br>
> cheers<br>
<br>
Greetings,<br>
<br>
Fred Jan<br>
<span class="">><br>
> 2015-08-01 15:18 GMT-03:00 Fred Jan Kraan <<a href="mailto:fjkraan@xs4all.nl">fjkraan@xs4all.nl</a><br>
</span>> <mailto:<a href="mailto:fjkraan@xs4all.nl">fjkraan@xs4all.nl</a>>>:<br>
<div><div class="h5">><br>
> Hi Julian,<br>
><br>
> Thank you for your report. I am not the expert, just one of the current<br>
> maintainers if the cyclone set of objects. I think the object works, but<br>
> maybe not as the Max object. If this is the case I will try to fix it.<br>
><br>
> > Hello,<br>
> ><br>
> > I am sorry to bother you but I have an important question about the<br>
> > buffir~ object.<br>
> > I hope you can help me with this. I am not too experiencd with PD<br>
> but I<br>
> > try to make<br>
> > an Binaural-Renderer. I want to use the buffir~ object to convolve<br>
> an IR<br>
> > to a signal.<br>
> > This works right now. But I want to change the IR used for convolving<br>
> > with the signal<br>
> > when the head orientation changes. I had a look at the MAX/MSP 5<br>
> > documentation<br>
> > as I understand this object was taken from MAX where the buffir~<br>
> object<br>
> > can be told<br>
> > to change the buffer~ object by using the set message. I tried this in<br>
> > PD but nothing<br>
> > happens. Obviously the IR is not loaded as there is no signal passing<br>
> > through the<br>
> > buffir~ object when using $1 as the name of the table and send a<br>
> message<br>
> > [set tablename]<br>
> > to input 1 (the signal input where the clear message can be<br>
> applied). Is<br>
> > this function<br>
> > not implemented in the PD buffir~ object? Or is there something I<br>
> do wrong?<br>
><br>
> Note '$1' is not literary part of the name, just a placeholder of the<br>
> first element on the message (=list) you send to the object. If<br>
> something is wrong here, the console should contain an error message.<br>
> Also see the help on $-variables.<br>
> ><br>
> > I would be verry happy if could help me with this question! If this is<br>
> > not implemented<br>
> > and can't be worked around do you have any ideas how to solve my<br>
> problem?<br>
> > Thank you very much in advance!<br>
><br>
> The attached patch is an adaptation of the help-patch, including a<br>
> second buffer to switch to. Yo need to open it and draw non-zero values<br>
> to get a signal through. It looks like you also have to provide the<br>
> offset and length arguments, as leaving them out results in zero -<br>
> meaning no useful convolution takes place.<br>
><br>
> When I have time, I'll check the behaviour of the Max5 object. It might<br>
> work better or more user friendly. But first on the planning are some<br>
> weeks vacation :-).<br>
> ><br>
> > Regards Julian Jochheim<br>
> ><br>
><br>
> Greetings,<br>
><br>
> Fred Jan<br>
><br>
> P.S. I added the pd-list in the reply, the main forum for issues like<br>
> this one (<a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a>).<br>
><br>
> _______________________________________________<br>
</div></div>> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> <mailto:<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a>> mailing list<br>
<div class="HOEnZb"><div class="h5">> UNSUBSCRIBE and account-management -><br>
> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>