oh, and do you think there is a way to get that 'reflection prevention' from the frequency shifter done in vanilla pd? i had a look at the vanilla butterworth filter, but it was a bit tricky for me to figure out how to get it going efficiently enough to warrant putting it in the patch.

i assume the 'reflection prevention' is just a fancy way of sayign 'anti-aliasing', right?

anyway, the normal frequency shifter sounds great to me. have included that already.

well one could do the same as i've done with the thunder to make it more sparse... slowly clip the control (the one which is send through pow(x,6)) signal so only positive values get through... if you do this with all 3 droplets you can half the amount and if you want even more switch off / fade out the droplets completely... maybe all done with a new slider... at .9 start fade out half of droplet one, at .7 droplet 2, at .5 droplet 3 everything over a range of .2... and then the same thing with a range of .1 to fade the droplets completely out....
man i just should have done this... its easier than to describe it >_<
damn i just saw that positive and negative values give the osc a completely different frequency

what's the name of the vanilla butterworth? don't even know it ^.^
it's not really aliasing... i think?... i try to filter out all the frequencys which would go out of the audible range after the freqshift... therefore i need a very steep filter
those frequencys would reflect at 0hz or the nyquist-frequency... and its obvious what would happen in a feedback loop if i let them stay... they would reflect again and again... say a 1000hz shift on a 800hz frequency would lead to an alternating 800hz and 200hz... and a 500hz would stay where it is

there is a butterworth filter in the help files, it's just made from the rudimentary cpole / rpole filters in pd.

ugghhhh that thing
i always hated it and didn't even try to understand it
i'm not that good with filters.. maybe you'll find a way
i think its enough if its really steep...
maybe you can use the helpfile butterworth as a lp and the normal hip as the hp... but in my tests the hp was the more critical one... it let through much much more... i intended to do it with only hp/lp 4 or 6 but 10 seemed like a better choice
but maybe you can get the helpfile butterworth to do real lop.. couldn't figure out the values for that.. then you would need only one filter and switch when the user switches between up/down shifting

found a bug... both mono-pureverbs have useless wet sliders
btw what's the difference between the two?
i saw that there are some values different... but didn't make a listening test

oh, the pureverb4~ was an experimental one with a block overlap of 4. it was left in there by mistake. it never really worked correctly. the idea was meant to be that it would really thicken the reverb by having the overlap, but somehow it always seemed to introduce some weird pitch shifting thing that i couldn't figure out. it has been taken out of the next update.

i played around with these reverbs a few weeks ago, and i think i may have fixed that wet slider issue, but i will check again to be sure, cheers.

it just wasn't connected where it should be... like in the st versions

the fft reverb confused me faster than i could close the window...
do you have any links or whatever about it?

it's just ripped from one of the pd help files, i think.

do you already have a gate object? one of the things i miss and didn't build myself jet

also for the 808_multi* abstractions... do you see a way to set/display a name for the individual substates?
remembering 1000 numbers might be a bit too much
just asking... there is always a way to take notes... at least with comments

your (mmb's) bitcrusher has a bug on lower bitdepths it introduces a dc offset
its because of your int where 1.5 ->1 but -1.5 -> -2 but a normal int isn't much better because it maps -.9 to .9 onto 0
you should make it all positive
instead of * bitdepth it should be (sig+1)*bitdepth and sig/bitdepth-1

yeah, i made a simple gate with threshold, attack, and release.

i think the easiest way to do display names, would be to make a little subpatch (or abstraction) with a symbol box, and connect the inlets and outlets of the signal box to an 808_state abstraction. that way, whenever you change state, the symbol box would also be updated.

ok, will fix that bitcrusher. i think there are a few objects which introduce DC offset, and it's something i had never paid too much attention too. but with the new library, i included a simple oscilloscope so that sort of thing becomes more obvious to me.

also, i packaged up that nice bitbasher maelstorm posted the other day.

ah good then i'll just wait for the gate

i'll try this

yeah the oto thingy is interesting
what lop did you use?

none, i just bundled up the bitmasher.

Thanks, mod! There's stuff in that library based on the work some crazy-good Pders. It's quite a compliment to know that I made something worth adding.

>>instead of * bitdepth it should be (sig+1)*bitdepth and sig/bitdepth-1<<

i changed that, and still noticed some offset on the very lowest values, so i changed the int to [expr~ int($v1+0.5)] and it works almost perfectly.

cheers for the bugreport

mael, have you got anything else that would fit in well? i'm only too happy to include it.

all suggestions are welcome.

Not sure. I'll dig around my hard drive and see if I find anything, but I think I have mostly unfinished projects. ;-p

oh man, don't get me started on unfinished projects. on some broken hard drive somewhere, there is a pd impulse tracker clone that i worked on for weeks and weeks, and eventually gave up on because the gui couldn't hack it, and the patch got too complicated.

then, there's the dx7 clone that very nearly got finished and left aside for other work. (it was way more than just a standard 6 op fm thing, i had researched pretty much the whole thing, and had patched most functions of the synth in good detail),,,but then it just got too hard in the end and i left it unfinished.

i think, that this is probably the 2nd biggest shortfall of pd. the first is certainly the gui. my commodore 16 could handle graphics better than pd does. but a close second is the 'unfinishability' factor. once you start making large and complicated patches, they inevitably get really hard to complete.

actually, this library project was born from the fact that i had made heaps of stuff as part of other patches, and needed a place to keep it all safe from the trash bin.

[expr~ int($v1+0.5)] has still the bug but [expr~ rint($v1)] not (at least in expr)
if you want to use wrap for vanillas sake you have to use my calculation.... if you want to i'll build it
or is expr vanilla? don't know *blushes*

next bug:
your combfilter works with z~ which isn't samplerate independent
with G05 you can make 1 block delays on 44.1k which will be 2 block delays @88.2k
the bad thing is i think delread~ does some kind of interpolation

some time ago i found buzzer+clank... shall i make a diy of them? and in which category do the fall? perk? or something new?
i think we need more weird stuff like these

what about the coming sequencers
will they have variable divisions like the diy-metro + diy-beat combination?
will there be at least one which has the ability to offset the beat? a while ago i made a ugly sequencer which could bang at 10 (normal) or +- 90%
10.45 (+ 90%); 9.55(-90%)...... kind of like the idea but didn't use it much till now
and will they have enough values per beat to make fancy stuff?

why not expand the rbg utility to the font colour and place the label into the slider to tighten up the interface
this could reduce the needed space down to 50-60% (?)

unfinished projects: the slurscreamer.... maybe i should name it this way to get my motivation back
its a try to make a tubescreamer in pd with complex clipping (already done) and a crapload of nasty features and feedback (not done)