Posted
Hi,
I am finding that I would like to automate certain sequences of transformations automatically using macros or rules rather than doing manual applications with Synfire.
Obviously, I am still learning the software and perhaps this functionality is already in there and I have foolishly not gotten to it. In that case, a pointer to it would be greatly helpful.
On the other hand, if the facility is not there, then it would be appreciated. For example, a sequence such as :
For a sequence of measures from 1 to 4 do:
for measure 1 invert all notes around the root;
for measure 2 do nothing;
for measure 3 quantize to 1/4 notes;
for measure 4 do nothing.
This kind of macro programming or rules facility is found in a lot of software (Word, Excel and some musical systems, like Capy Talk in Kyma, that I also use) and there are people that become, naturally, macro power programmers in their own right in this systems (most notable in spreadsheet and word processors).
Will there be a Cognitone Controlled Language for applying gestures, features, transitional rules etc... and vectors to note or note sequences? For example, I can easily imagine in applying an "arpeggio" macro to every downbeat on a 4/4 four on the floor dance track and it would be much easier to just have some stored macros and apply them.
In this way I could index notes and apply the Phrase Editor transformations without having to do them manually by selection. Just a thought?
Forgive my ignorance if this is already in the software - as I mentioned, I am still learning.
I would be interested in what others have to say :)
Thanks!
Mi., 04.01.2012 - 17:21 Permalink
There are no macros yet. We are still collecting ideas. Many suggestions have been made in this direction. Finding the right set of object accessors and primitive operations is a tough challenge.
It's easy to hack a scripting engine, but without a clear design and goal, it would be a wasted effort. One scenario I definitely want to avoid is that we invest time and money in developing a scripting system, of which only one or two features will be widely used, because all the others turn out to be useless, redundant, or not leading to musically meaningful results.
The pure logical elegance of a powerful "language" alone does not prove anything with respect to its musical output. The only way to tell the useful ideas from the useless is experimentation. We welcome all users who want to do such experiments and share their findings here. The more input we get, the better.
At the moment however, the priority for adding scripting features is secondary. First we need to get the user interface right (that is, easier accessible and more comfortable to use) and address a few weaknesses that have been on the agenda for a long time already.
Mi., 04.01.2012 - 17:40 Permalink
That is also a point for me
With SFP you can assemble a whole library of phrases and figures and work with that
I think this is very valuable, because those copied segments/phrases are probably very difficult to make by hand with the segement manupulation tools in SFP ( seems to me ? )
There are the standard motive transformation ( for a melody)
- sequenze
- Side slip
- Rhythmic displacement
- inversions
-etc
I must translate this to the segment manipulation tools ( flip, etc)
Mi., 04.01.2012 - 18:43 Permalink
I agree that this is secondary to ease of use and am strongly in favor of the experimental method.
The key in macro language design is also ease of use and integration into the GUI tools.
A visual, heierachical rule / macro application layer would be more useful than writing programming code in text --- a visual tree-structured diagram with a hierarchiy of the unit transforms might be the way forward but that is a real challenge in GUI design and coding as well. Also, paramount to a capability like this is the ability to reference indrectly via indices.
For example, it is much easier to refer to a span of notes and note (relative) positions than to be forced to address each note ( that wou;ld be what a gui=-based selector does for you). Howwever, to keep note objects referencable it might also be important to identify the primitive types of the most musically useful expressions.
For example, this could be dpne initially with a rule or macro language facility incrementally exposed before building a GUI layer.
There are several controlled musical languages out there and it might be useful to look at some of the popular operators in those ... but this is all secondary though perhaps strategically important tp consider.
:)