Hi, looking at the lmnts help file, seems none of the blow or strike parameters do anything...then looking at the code in Github https://github.com/TheTechnobear/Mi4Pd/blob/master/lmnts/lmnts~.cpp#L163-L166, it looks like it's been disabled.

Does that sound about right? Are samples in the actual hardware, therefore subject to copyright stuff etc..?

Of course can make our own impulse..but just struck (no pun intended) me as a little odd.

Just re-read this after some time (2ys)!

Seems like the ELSE library is the key to all things noise and random

@Spacechild1 said:

thank Apple for their stupid arbitrary design decisions

Seriously, it's not the first time I've heard that!

sweet thanks! new browsers look like a work of art

has there been any further development on the macOS gui thread work? I frequently use plugins that have their own preset system (like Diva for example) and that means using the gui to find the presets and on plugins like that tweaking them is a lot easier. I do save out the state into a vst preset file or message box afterwards for easier recall...it's just a bit more long-winded

cheers

I have wondered why Pd doesn't seem to have more of these types of primitives in the standard library (i.e. [pink~] [grey~] [brown~] [jitter~] etc)

@shreeswifty said:

to build bamboo~ and other physical models you need to have stk~ in the sauce
https://ccrma.stanford.edu/software/stk/

ah right like fftw for [bsaylor/pvoc~]? brew install stk should work then

@seb-harmonik.ar That's great thank you. Confirming the lib loads for me, though a few objects don't seem to output anything for me (bamboo~)

Hi

I only seem to have a 32 bit build. Has anyone successfully built a 64 bit of this library (for Pd-0.50.2), or know where I might be found? I'm interested in the macOS version primarily.

Many thanks

Yes I agree that presets only local to a single instance of an abstraction is a bit limiting.

So it’s the multiple abstraction states saved as presets in the parent patch, that I can I can recall at any time, either by a little gui, or messages, that would be my preference.

I can’t see how I would achieve that on a global [savestate] level, unless I can poll all the [savestate]s inside the abstractions into a global text object and save that into a parent based save [savestate] maybe

@weightless said:

At that point, I think it's more efficient if the presets are stored in text files so that they can be shared by all instances of the abstraction.

@weightless How would this work in the context of [savestate] - the text files would be loaded into each instance of the abstraction individually, or as one global preset load? (sorry I'm probably over-thinking it here!)

I had it in my mind as a global patch state, a bit like SSSAD which I used a lot in the past but I guess this how [savestate] is working anyway. A later development to the initial sssad work brought an abstraction (can't remember the author) called [presetstore] which allowed you to save multiple global states in one patch. I guess what I'm trying to avoid is saving multiple versions of one patch, as it seems inefficient to me.

@ingox said:

[savestate] may allow to include the [text] to store the presets individually inside the abstraction, which could be beneficiary.

@ingox that is a good point!

cheers all