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 <[email protected]>: > 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 > > > > > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
