Having had a look at a couple of examples the AMH format looks reasonably clear and easy to understand but there are some elements I'd be interested to see documented, in particular the format of the "range-timepoints" element.
I'm guessing it's a series of lines encoding time-position | min | max but there are some oddities that are giving me pause for thought.
If this is documented anywhere (I searched Google to no avail) or if anyone has already done this leg work and is happy to share it, that would be very useful.
Thanks.
Matt
p.s. My aim to begin with is to create an automation curve smoothing script.
Okay so I took a little time this evening to have a crack at this problem. The AudioMulch XML is a little problematic from an interoperability perspective in that it uses significant whitespace for series data like the data but it's nothing we can't get around.
I have implemented a script that rewrites automation data for any min-max property (e.g. BubbleBlower Amplitude) and reduces the number of automation points in half using averaging. It's mostly as a proof-of-concept rather than because this is, in itself, useful.
What I can imagine is using it to generating smoother curves with different shapes but that's not an evenings math.
Anyway if anyone would like to try it out the scripts are here:
https://github.com/mmower/mulchworks
Cheers,
Matt
I'm not sure how obvious it is to work out what I'm doing from what I've written (it's getting late) so I just uploaded an image that shows a before/after shot:
[url=http://cl.ly/0Y3X2m0l1P0R2T3U1q42][img=750x675]http://cl.ly/0Y3X2m0l1P0R2T3U1q42/smoothing1.png[/img][/url]
Hopefully you can see that the lower (smoothed) automation lane uses half the points for the same curve.
Better analysis could do more interesting things but that's for the future.
m/
pretty nice. I've been envisioning generative scores and generative patching ever since Ross switched over to xml, but never got around to it (it's only been what, 10 years? :-) . I would be interested in seeing some documentation on the format as well.
Hi Matt
> The AudioMulch XML is a little problematic from an interoperability perspective
I think you'll find that the parser is rather tolerant to whitespace
However, the format is not intended for interoperability and may change without notice (in which case the document version number will change). Often it is necessary for me to extend the format when new features are added to AudioMulch or to fix bugs. New versions of AudioMulch can load all old-format documents however the format has changed in quite significant ways between releases. That is one reason the format is undocumented. Depend on the format at your own peril.
That said, if you do need something explained I'm happy to provide details on the meaning of elements in the document.
Hope that helps.
Ross.