Hi Shannon, > Moselle looks pretty interesting. I'm tempted to give it a test run.
Give it a shot, why not! > I assume you're looking for feedback on the software, however, just looking at the website, a couple things spring to mind. The software itself, the sound modules, website, anything, thanks! > As a programmer, good documentation makes it easier to get started with a new tool. Take Vuejs for example. > There is a "Guide" which shows how to use Vue. (Great when you're a Right. When you fire up Moselle it loads a "default" patch and displays it. When shipped, the default patch is a patch telling you how to find the first lesson of the tutorial series. That is a set of 170+ patches, each with a lot of explanation telling you how Moselle works, how that patch in particular works, how to play it and hear the specific features it's meant to illustrate, and so on. If this is too in-depth and time-consuming, the website's "Overview" page is in effect a "PowerPoint" presentation that should leave you understanding very well what Moselle does and doesn't do, although it won't leave you actually knowing the specifics of how to do it. > There is a "API" which works as a reference once you know what you're doing. Yes, I'm working on such a document, which will be about half reference. What I find though is that while developing it, I just turn to the Tutorial section to see exactly how something works. The doc also has a "reference sheet" which perhaps I should make available now without waiting until the manual is done. I should also probably put that on the website, hot-linked to more detailed info.. >- There are "Examples" which provide a bit more information about how Vue works in practice. The tutorial series covers this, but min is not "a bit more info," it is, I think, absolutely every detail. (Again, if you see anything I've missed let me know.) > Can Moselle modules run at different sampling rates? This version, Alpha 5, all runs at audio speed, which is a figure in a config file, that is read once when the program starts. It ships with 44100Hz, but can be changed. (Extreme changes will probably require changing buffer sizes etc) Currently the entire patch runs at that speed. I have a design for multiple-speeds, but it's not implemented yet. This is partly because all components can run at audio speed. It's hard to come up with a heuristic to decide that an envelope should be evaluated, at, say, a 1/16th speed "control" rate, as the envelope might be being used as an oscillator. Of course if its segment times are all constants, I could simply figure out its speed, but in practice they'll probably be controlled by MIDI inputs or other modules. Similarly, audio oscillators and filters work fine at control speeds. Also, the interpreter/compiler is highly optimizing and notes where variables can be updated only upon MIDI information receipt. EG: saying "Frequency = Global:FreqA + ( Voice:Note - 69 ) semis" won't bother recalculating Frequency unless the MIDI note changes... (which happens, of course, with legato mono playing) (FreqA is in the config file but ships as 440Hz. 69 is the MIDI note number of A4.) Due to this optimization, there may be less need to run patches at multiple speeds. > For example, it could be beneficial to oversample the audio inside a distortion module, and run the final mixer module at the lower project sample rate. I don't have a design allowing a module to oversample. My workaround is to just run the whole thing at the highest speed you want (currently), or (soon) run the patch at the highest speed but then run most of the modules in the patch at lower speeds.
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
