One idea I have for my theoretical computer music language is having scheduling built right into the syntax, with the hopes that it will add the right balance of functionality and clarity.
I like the idea of having a score language separate from the orchestra language, though I’ve learned over the years that this approach acts as a bottle neck. The @ scheduler is a potential solution to bring both together, without losing the purpose of the score.
Instead of going into great detail on how the @ scheduler might work, I’ll just present the following four examples.
Example 1 — Nested Time:
do_something() # Do something at beat 0, (@0 assumed)
@2 do_something() # Do something at beat 2
@5:
do_something() # Do something at beat 5: 5 + 0, (@0 assumed)
@3 do_something() # Do something at beat 8: 5 + 3
@4: # Block starts at beat 9: 5 + 4
do_something() # Do something at beat 9: 5 + 4 + 0, (@0 assumed)
@1 do_something() # Do something at beat 10: 5 + 4 + 1
Example 2 — Changing values mid-event:
def foo():
freq = 440 # Initial frequency
@1 freq *= 2 # Frequncy doubles at time 1
output Wavetable.osc(1, freq, sine(8192)) # Output signal
Example 3 — Scheduler error:
def foo():
@1 freq = 440
output Wavetable.osc(1, freq, sine(8192)) # Broken, freq doesn't exist
Example 4 — Organized score + generated events:
def hat_eights():
for i in range(0, 8):
@(i / 2.0) hat()
@0:
hat_eights()
@0 kick()
@1 snare()
@2 kick()
@3 snare()
@4:
hat_eights()
@0 kick()
@1 snare()
@2 kick()
@2.5 kick()
@3 snare()
That last example reminds me of Max Mathews’ Radio Baton Conductor language.
I really like where you’re going with this. Your “@” idea reminds me of the way scheduling is handled in chuck. Have you ever looked at Impromptu? It’s scheme-based, and handles scheduling via a completely different mechanism, using callbacks in a temporal recursion sort of way. Impromptu is really more for live coding and leverages AU’s for sound generation, although he’s been adding some simple DSP code in the last couple versions.
I like where you’re going with this and you’ve really got my wheels turning!
-pete-
@pete_m: Thank! Yeah, the ‘@’ is very much in line with ChucK. Probably the original source for my inspiration. I’ve not looked at Impromptu, though I’m adding it to my list of things to play with.
As for live coding, it’s too early to say, but I think slipmat, if it ever gets off the ground, would be another live-coding capable language. It may also evolve into a visual language as well.
If you ever have any thoughts, please share! I’m collecting ideas for the next 6 months.
Pingback: Slipmat » When Does That Happen?
Hi,
I really like this brainstorming, but I can’t get out of my mind words from James McCartney, who said about supercollider, that if he could start again, he would not make up a whole new syntax. (I don’t remember where I read that…)
So I’m thinking the scheduler might be completely python compatible of it looked something like:
do_something() # Do something at beat 0, (@0 assumed)
_S(2,do_something()) # Do something at beat 2
_S(5,[do_something(), # Do something at beat 5: 5 + 0, (@0 assumed)
_S(3,do_something()],
_S(4,[do_something(),
_S(1, do_something()])
what do you think?
Cheers,
Andrés
Sorry, was really hard to edit…
This is what I meant:
do_something() # Do something at beat 0, (@0 assumed)
_S(2,do_something()) # Do something at beat 2
_S(5,[do_something(), # Do something at beat 5: 5 + 0, (@0 assumed)
_S(3,do_something(),
_S(4,[do_something(),
_S(1, do_something())]
)
)
Pfff… This is it now:
do_something() # Do something at beat 0, (@0 assumed)
_S(2,do_something()) # Do something at beat 2
_S(5,[do_something(), # Do something at beat 5: 5 + 0, (@0 assumed)
_S(3,do_something(),
_S(4,[do_something(),
_S(1, do_something())] ]
)
)
But it does prove that this syntax easy leads to errors….
It would be better to define the lists first and then pass them to the scheduler…
Cheers,
Andrés
@Andrés
Having played with writing mock computer music code on and off for the past 10 years, all I can say is that there is a lot of truth to what James McCartney said. Some of the stuff I’ve come up with was truly horrid.
So far, I’ve personally found that utilizing a special symbol and placing at the beginning of a line of code has increased the legibility of the code. However, I do recognize that I’m in the thick of it and am completely biased, which is part of the reason why I’m making these ideas public. I know that just because I think it’s a good idea does not make it so.
To get back to the point about not coming up with a whole new language. If I don’t make any other significant changes to the syntax, I would consider this to be an augmentation rather than making up a whole new language. Since music and visuals are time based in time, it makes sense to consider incorporating elements of time right into the language. Both in terms of functionally and aesthetics.
That said, it still may make more sense later to go with something closer to your suggestions than mine. The @ scheduler may or may not make the cut.
@Andrés
And by the way, thanks for taking the time to posting your thoughts. I’m collecting ideas for the next 6 to 12 months. I’ve already been influenced by some of the comments I’ve read here and on the Csound mailing list in response to this blog.
Hi,
Thinking in practical terms, if you make no additions to python syntax, you could make slipmat just a set of python modules. This has the great advantage of having all of python there, ready to play with. Need numpy? There. Need Qt? There. Need network, etc…..
Time is limited, and instead of having to build a parser/ interpreter, it might be good going with preexistent languages. Python also has the advantage of being interpreted, so it’s extremely suited for live coding.
The main issue would be speed, but if the modules are written in C, it should be fast enough.
Cheers,
Andrés
@Andrés
Believe me, that is something I am considering. It might even be possible to do what Processing does, which preprocesses code and converts it into Java. (at least that’s my understanding) So it might be possible to convert slipmat code into Python, or some other language. Michael Gogins believes Lua is better equipped, so I’ll be checking that out at some point.
I’ve never tried Lua, so I’d be interested in your experience.
Cheers,
Andrés
Pingback: Slipmat » Lists as Micro-Sequencers
Pingback: Slipmat » The Slipcue