Some pieces can be split into multiple fragments. In order to express how they depend on each other and on any input audio file, and also to automatically manage parallel generation, a Makefile approach can be used.
One approach is to implement this directly in Python, using functionality from Splat to work out the dependencies and run the fragment generators. However, it would mean spawning other Python processes to achieve parallel generation as Python doesn't handle threads very well. It would also mean implementing a way to resolve dependency chains. The advantage of this approach is that it would be portable and self-contained within Splat.
A second approach is to generate a Makefile to be used by make. This would just rely on a Splat utility to import a main module, rely on some convention to find the dependencies on other fragments and input files and generate a Makefile automatically. It could be saved as a file or generated and passed on standard input for each build. The main advantage is that it should be much easier to implement and would make use of all the standard make features to resolve dependencies, detect change dates and generate fragments in parallel with different processes.
A third potential approach would be to have a standard set of make rules that are created dynamically by relying on the same convention as in the 2nd approach. In this case, the Makefile would call a Splat utility to generate the dependencies and targets on the fly. This might be less flexible and not practical, but worth considering.
Some pieces can be split into multiple fragments. In order to express how they depend on each other and on any input audio file, and also to automatically manage parallel generation, a Makefile approach can be used.
One approach is to implement this directly in Python, using functionality from Splat to work out the dependencies and run the fragment generators. However, it would mean spawning other Python processes to achieve parallel generation as Python doesn't handle threads very well. It would also mean implementing a way to resolve dependency chains. The advantage of this approach is that it would be portable and self-contained within Splat.
A second approach is to generate a Makefile to be used by
make
. This would just rely on a Splat utility to import a main module, rely on some convention to find the dependencies on other fragments and input files and generate a Makefile automatically. It could be saved as a file or generated and passed on standard input for each build. The main advantage is that it should be much easier to implement and would make use of all the standard make features to resolve dependencies, detect change dates and generate fragments in parallel with different processes.A third potential approach would be to have a standard set of
make
rules that are created dynamically by relying on the same convention as in the 2nd approach. In this case, the Makefile would call a Splat utility to generate the dependencies and targets on the fly. This might be less flexible and not practical, but worth considering.