From the original SynthMaker forum (2004–2014), with its members’ names and dates.
VPDannyMan ·
Has anyone taken the Multi-mode Biquad filters from the Wiki and updated them. I was wondering as I have not found any ASM optimized versions of these filters anywhere? Also, could those coefs not be calculated with Green data, if for example you were not using those filters to oscilate, but say for example as an eq of sorts? In this situation it seems to me that one would not need to calculate them for every sample?
aliasant ·
VPDannyMan wrote: Has anyone taken the Multi-mode Biquad filters from the Wiki and updated them. I was wondering as I have not found any ASM optimized versions of these filters anywhere? Also, could those coefs not be calculated with Green data, if for example you were not using those filters to oscilate, but say for example as an eq of sorts? In this situation it seems to me that one would not need to calculate them for every sample?
Instead of doing it all in green you could hop that part of the code by say, 128 or maybe even 512. If the code is hoped it wont use more then 1 or 2 cycles.
VPDannyMan ·
Interesting...You sure that green math would not bet better though?
MegaHurtz ·
You can diy it, based on dozius filterpack. Or use the stock one.
aliasant ·
VPDannyMan wrote: Interesting...You sure that green math would not bet better though?
Well. You would save a few cycles but you would also need a lot of green primitives + the work. If you use the hopped code you wouldnt really need dezippers to get smooth transitions so thats another save..
Back in the days when computers were built by and used by real men/nerds computers were slow and a few cycles here and there ment a lot. Times change but if your going to use a lot of these filters maybe you want to save those few cycles and clutter your schematic with all those green little monsters and dezippers and what not.
🙂
Tzarls ·
And if you want to use ASM you could put the code to calculate the coefficients inside a jz and use a pointer to only execute the calculations when then cutoff changes.
aliasant ·
Tzarls wrote: And if you want to use ASM you could put the code to calculate the coefficients inside a jz and use a pointer to only execute the calculations when then cutoff changes.
Da.n
Is there any ways to see that asm jz in an example?
stw ·
aliasant wrote: Tzarls wrote: And if you want to use ASM you could put the code to calculate the coefficients inside a jz and use a pointer to only execute the calculations when then cutoff changes.
Da.n
Is there any ways to see that asm jz in an example?
I guess it can be simplified but it should work like this.
Tzarls ·
Exactly, you place the code that must only be executed when the coeffs change between the "jz end1;" and the "end1;".
infuzion ·
aliasant wrote: Instead of doing it all in green you could hop that part of the code by say, 128 or maybe even 512. If the code is hoped it wont use more then 1 or 2 cycles.
+ the 5 or so cycles of the hop() function itself.
exonerate ·
VPDannyMan wrote: Has anyone taken the Multi-mode Biquad filters from the Wiki and updated them. I was wondering as I have not found any ASM optimized versions of these filters anywhere? Also, could those coefs not be calculated with Green data, if for example you were not using those filters to oscilate, but say for example as an eq of sorts? In this situation it seems to me that one would not need to calculate them for every sample?
In the developer toolkit there are green versions of the coefficient calculations for the filters used in the multimode biquad.
You can use them with the biquad filter primtive that come with SM which takes coefficients as input.
Cheers 😉
Exo
Dozius ·
stw wrote: aliasant wrote: Tzarls wrote: And if you want to use ASM you could put the code to calculate the coefficients inside a jz and use a pointer to only execute the calculations when then cutoff changes.
Da.n
Is there any ways to see that asm jz in an example?
I guess it can be simplified but it should work like this.
I remember playing around with this very idea before but I found the overhead was too much to be worth it. I just used hops.
stw ·
Dozius wrote: I remember playing around with this very idea before but I found the overhead was too much to be worth it. I just used hops.
That's true. I don't have an idea where this could be really useful. I think it's much leaner when doing only the hops or put the "if changed" thing in green.
aliasant ·
Is this the way the green data works in SM? or in any program? If so the overhead shouldnt be any bigger then if using green primitives right? On the other hand. f that jz code is running at samplerate and only letting the wrapped code thru when changed, then the overhead is to much. Maybe usefull if using a huge green part.
Whish we had green coding possibilities though 🙂
But again.
How does the green stuff really work in SM if it isnt done with this jz thing?
infuzion ·
stw wrote: Dozius wrote: I remember playing around with this very idea before but I found the overhead was too much to be worth it. I just used hops.
That's true. I don't have an idea where this could be really useful. I think it's much leaner when doing only the hops or put the "if changed" thing in green.
I don't think you need to do a "if changed", just the Float Sample & Hold primitive for this purpose, since you only need to worry about the Code/ASM reading whatever is connected to it. I don't think you have to worry about too many green false-triggers, & if that is the case, then put the "if changed" in/after the knobs.
VPDannyMan ·
Wow thanks guys...a lot of good info to mul over(pun intended)
(For those that don't get it, mul as in mulps) haha, yeah I know pretty bad...
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker