This is really fantastic. Getting Automation Lane and CV Recorder working together under one hood might be worth considering. The idea would be that you could do a filter sweep or whatever, but then you would have a spline to work with as a result. Is that possible/difficult/redundant?
Taking it further has there been a spline module that allows you to modulate the spline amplitude points? I think one of the barriers to meaningful ‘FM’ can be a lack of visual layering so that as you start to modulate the modulators that are modulating other modulators (and so on…), any help in seeing the epicycles can cue the ear into the differences morphing.
Here is the final draft for v1 of the library. I know, I know, something here or there is missing, like there aren’t many effects, but it has to stop at some point. There will be more iterative updates after this comes out that will be more frequent, but keep in mind that for every module I have to write 1-2 pages of documentation.
What I’d love is if people have the time or inclination to go through this and tell me if anything is broken or a default value is off or something is offcentered.
Thanks to everyone who contributed to this massive rewrite of this library! @stschoen@robertsyrett@sansnom contributed the most I believe, but there’s countless examples of good advice given here on this thread and elsewhere on the forum - so THANK YOU!
Looks good. I did notice that the basic VCO doesn’t clamp the frequency at 0 hz, so it is exactly the same as the TZFM VCO, unless I am missing something.
You’re welcome! Basic VCO uses Osc nodes whereas TZFM uses phasors - the basic VCO won’t run backwards, and the TZFM isn’t anti-aliased, so that’s the diff.
Ah, the LED indicating through zero modulation might be a bit confusing then. But I see there is indeed osc nodes inside ^^ which will respond like an analog oscillator to FM.
Here’s a link to the evolving Module Library Documentation. Just barely started on it, so go easy on me! Would love to hear initial feedback - don’t worry about editing/particular stuff here or there, just the broad strokes of organization and how it looks.
I notice there are some pages that are either completely or mostly blank. I have some experience fighting against (pdf)LaTeX and would be happy to try to help in the fight.
Additionally, In the early parts of the document (before the module reference) I feel like some pictures could really help with explaining how things are hooked up.
Edit: and the left-vs-right page formatting LaTeX applies by default are probably not ideal for a primarily online document. Again, I’d be happy to try to bring that under control.
Thanks @Medgno for the offer! Right now the easy part is actually labeling what each knob does, so that’ll go pretty quickly. What I plan to do after that is for each module show a few example patches with descriptions on how to get the most out of them. In other words, thanks for the offer, but there’s plenty of time for me to chip away at this!
Oh and yeah I was going to google how to fix that - do you know what search terms I could use, or how to do it? I’m sure it has something to do with the book class.
I finished all the tables for each module. What I’m doing now is going through all the entries and adding more lengthy descriptions including useage examples.
I also found it’s pretty easy to add both a glossary and an index, so I’ll be doing that as well!
Mark: looks good. Have you considered wiki-izing the documentation?
There is a lot of great discussion in the forum some of which (in distilled form) would make great additions to the docs. I have had many questions whose answers I found in the forum rather than the docs – and when those sorts of things happen, I would be happy to be able to add the information to the docs to spare some future soul the search.
I think if we’d do this, it would have to be something separate like “The Big Book of Audulus Forum Knowledge.” There’s a lot of particulars about this manual that I just kinda need to do on my own, and though it would be great to split the work, it would probably take longer to go through what everyone had written and edit it than it would to write it myself.
But there are things on the forum that haven’t or won’t make it into this doc in particular, especially since this is just about the module library. Maybe start a new thread to get ideas going on how we could make that work?
FWIW, one of my big regrets on a large (obscure) set of reference docs that I wrote over many yeas was not having written it as a web doc that other knowledgeable users could contribute to and edit after I’d posted it. There are a number of great wiki architectures and they all offer fairly friendly rollbacks or revisions and comparisons of doc versions.
By the time that I realized how beneficial it would be, I had invested a ton of time in a format that would have been very time-consuming to break up into smaller wikiable components (benecial both to the community since it would have allowed the docs to be improved as shortcomings were found – and beneficial to me as in the long run it would have reduced the pain of revising and republishing the docs).
Yeah, but this doc is online on our Git and the source code is public, so I don’t know if it’d have that issue.
A big part of working in LaTeX here is so that we come up with a printable doc. It’s also much, much easier to use than writing in pure markdown which I was doing before on the website, and it produces a really nice looking result. So a totally web-based thing isn’t something we wanted to go with for this particular documentation.
So in short, I’m not opposed to a separate user-made doc that is a wiki, we just want to make sure that there are some centralized docs that have a cohesive vision and voice.
