Open jhw opened 5 years ago
Noted re sunvox tracks
OK I will do a separate PR for gitignore
I'll leave u to think about serialisation/deserialisation; yes I think it would be really nice, JSON is fine though would prefer YAML; I have no problem u using these PRs as food for thought and not actually merging them
You mean u like expand_chains
? Yes is a nice (but obvious) idea. Is
actually part of a separate thing I'm working on, I just used it here to
demonstrate the serialisation. I think graph
is a nice name for the
package. Give me some time as the code isn't complete yet .. need to do
something similar on the timeline side, but I'll commit a new PR for
graph
in the next week or so.
PS sorry it has taken me so long to collaborate. It must be 2 1/2 years now. Something spurred me to work on this in the last couple of weeks, looking forward to keeping some momentum up
Rgds
On Sat, 23 Feb 2019 at 19:36, Matthew R. Scott notifications@github.com wrote:
@gldnspud requested changes on this pull request.
I don't think we should merge this as-is, but would like to keep this PR open for us to discuss serialization and deserialization a little more, including the use cases we both have in mind. I would definitely like to see some sort of JSON-compatible encoding/decoding in radiant-voices!
Same comments from the other PR apply about including .sunvox files in this repo... I don't think we should include them unless they're small and contribute to automated tests.
In .gitignore https://github.com/metrasynth/radiant-voices/pull/23#discussion_r259588569 :
@@ -60,3 +60,12 @@ docs/_build .bootstrap .appveyor.token *.bak + +# virtualenv +
I'm OK with adding these... but it caused a merge conflict with a recent addition to master.
Could it be split into a separate PR?
In rv/tools/serialise.py https://github.com/metrasynth/radiant-voices/pull/23#discussion_r259589188 :
- return obj
- return json.loads(text, object_hook=sv_hook)
+if name=="main":
- try:
- import sys, os
- if len(sys.argv) < 2:
- raise RuntimeError("Please enter filename")
- filename=sys.argv[1]
- if not os.path.exists(filename):
- raise RuntimeError("File does not exist")
- if not filename.endswith(".sunvox"):
- raise RuntimeError("File must be a .sunvox file")
- from rv.readers.reader import read_sunvox_file
- proj=read_sunvox_file(filename)
- def expand_chains(proj):
I like this function! This is definitely in line with the extend SunVox https://metrasynth.readthedocs.io/en/latest/vision.html#extend-sunvox part of this project's vision.
Maybe a dedicated module or package for it... not sure what to call that module, any ideas? rv.analyze? rv.graph? rv.extract? (I'd be hesitant to call it rv.utils since we already have rv.tools for command line tools.)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/metrasynth/radiant-voices/pull/23#pullrequestreview-207120213, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAilAHB7K9Oca_xUMqXIwa52Tn53QC6ks5vQZgxgaJpZM4bJtCA .
So one thing I found I needed was the ability to serialise an individual module / chain of modules outside of a project, preferably in a human- readable form. As mentioned before am interested primarily in cutting apart existing tracks and remixing rather than creating from scratch - as such it's useful to be able to select a module from a "decompiled" track and store it for later use.
The
__main__
block of this script just demonstrates that thedumps
/loads
round-tripping works. It's made a bit complex by the fact that RV is so class driven, particularly the way enums are embedded within classes. Have to do a lot of dynamic loading of modules and classes. The implementation probably isn't optimal but maybe you have a nice idea from it. I used JSON as the base format as it has some nice parse/format extension hooks you can hang code off - would have preferred YAML but seemed more complex, didn't have time to investigate.Should probably have a similar serialisation mechanism for individual patterns as well as modules.
There's also a function
expand_chains
in the__main__
block which I find myself using a lot, will probably create a separate pull request for this and associated code in due course.