for history's sake, why not? Its just what I've learned to use. I kind of like it.tramp wrote:sorry, I didn't like cmake.
The reason for map is that some of them will use midi and I just copy paste a ttl template. I can take that out for the plugins that don't use it (currently all of them).
I'll double check harmonizer and distortion. Distortion was actually the one I've tested the most, it was working here, but I've touched it since. Thanks for the report!
Is this the answer to the question I sent to the lv2 dev mailing list? I really don't like the static size buffers I've made (it works with any size 1024 or less) but I didn't know any other way without some deep refactoring. Looking at the LV2 docs isn't especially enlightening on these extensions. Do you know any examples I can look at?falkTX wrote: for these plugins though the buf-size and options extension needs to be a requirement.
they were made with a static buffer-size in mind (because of jack and/or zyn), and buf-size + options is the only way to ensure that.
Git patches are great. I'm still trying to decide between just making a full new project or trying to refactor ALL of rakarrack so that this can get merged in. I'd rather not have to do all the refactoring, but there are worse things. If I do make a new project on sourceforge they have now a fork option, which I assume then gives you a pull request option somewhere. The working repo currently is a fork from the rakarrack sourceforge repo.falkTX wrote: @ssj71:
what's the best way to contribute?
I got used to github's fork + pull-requests that is now weird to do things old school...
are git-based patches ok?
Since we're already OT, is there any way to load files through the worker extension WITHOUT needing a UI? I looked through the eq_sampler on LV2 and I think the answer is no. I'd like to port the echotron module but loading files it seems has a lot of overhead compared to the other modules.
Thanks all, it's really great to have community support.