>>another suggestion: why not make a lib sub-folder. where you can store such things like modulate. or a scale log which then could work with arguments. <<

that's how i originally did it, but i just wanted to make it so that the modules would just 'work' even if they were removed from the library. i guess i was kind of successful in that regard, because i have spotted some of my drums and stuff inside other people's projects. the only abstraction they need is the 808_state for state saving, but they will work fine without that anyway.

>>currently i guess it would be annoying to change all modulates.<<

i sometimes have a lot of free time the other day i went through the whole library and replaced all the [loadbang] objects with a subpatch to allow for loadbang on dynamic creation. this meant changing around 100 patches and resaving them.

i will do DIY3 soon then. it is not 'finished', and i have some worries that it is not at all backwards compatible with DIY2, but at the end of the day i am a musician more than a programmer, so the function is what matters.

diy3 'upgrades' include:

a built in sound editor, so you can record loops and sounds and edit them within pd and then export them to .wav files.

some more 'synth' like modules and effects units (tape echo, etc)

inbuilt diy-clock module that ties everything together for sequencing, and then of course some sequencer modules.

vanilla pd compatibility (this unfortunately meant removing some really useful things like the 7 and 13 band EQ's, but they could always be imported from DIY2)

well if people take your instruments they can also take the necessary libs... its not that they have to get them at some unknown place in the internet.
but it would make your work easier... time you could spent on better things

looks like the next version will be even greater but don't rush it
seems like a great bunch of work

but couldn't you have found another solution for the vanilla compatibility?
something like mark those abstractions or put them in a sub-folder "non vanilla" or something?

but don't forget its your library so only your opinion matters

butt_counter == 5

i changed some stuff again and made the amount slider reflect the nature of the feedback much better
i listened to the original one like it was intended to sound and my version is much deeper
like the original is rain on concrete and my version is behind a window or on a softer material?

maybe one should make a 2*44,1khz version or tune all the filters to compensate the different samplerate

http://www.pdpatchrepo.info/hurleur/syn-rainS.pd

cheers, had a listen now just quietly, but it sounds good.

would be nice to be able to get even more sparse rain, just 1 or 2 drops per second, but i guess that may be hard?

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