Cheers,

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.

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

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.

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.

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

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())]

)

)

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