Re: [sc-users] Graphic sequencer interface programming

On Jun 16, 2009, at 12:42 PM, Mr.SpOOn wrote:

2009/6/16 Batuhan Bozkurt <batuhan@xxxxxxxxxxxxxxxxxx>
Hi Carlo, just some suggestions..

First of all, I want to say that "I've been there". I have a sort of experimental sequencer called "deQuencher" which I first coded with processing, then ported it to C++ with openframeworks but in the end I ended up redoing it in SC.

Hi :D
I already know your project and I think it was the main inspiration for my idea.

Thanks, that makes me happy!

There are good and bad things about both approaches of course. Java and C++ is much faster with GUI stuff and that is an added benefit. But sclang itself provides you with amazing timing/sound control structs out of the box, and if your GUI lives outside sclang domain, you will need to write all of those by yourself and send your own osc messages. A simple step sequencer can be written in 10 minutes inside SC with a nice GUI, but will probably take many hours in another environment and your will be severely limited by the lack of sound control mechanisms.

I don't really want to create a simple step sequencer. My main idea is to put sound objects on a bidimensional space and create time relationships between them. For example, there may be a global clock with a certain frequency; then I can put a snare and decide to play it at every click of the clock; then I can link a kick to the snare and specify to play 1 second (or some other time unit) after the snare and so on. What I have in mind is more complex, but this is just to explain the concept.

If you don't need hardware accelerated fancy graphics and effects, I see no reason for staying away from SC for duing the GUI for such stuff. I mean, using java or C++ has its own merits, but only if they do good for what you actually do.

I also need to save what I've done. For example, if I like a particular placement of my objects I want to save this configuration in an XML file. It would be great to save different patches and make them interact.

This is also doable, in fact thats what I do with the Hadron Quark (check out the screencast if you haven't done it already: http://www.batuhanbozkurt.com/projectslab/supercollider/hadron ). Saving states of your objects, instances, whatever form sclang is a lot easier. The two approaches require very different designs. In SC, you can save your stuff as strings to a text file, then load it and call .interpret on them, and they are ready. This won't be the case if you use Java, you will only be able to save client side information. Initializing everything back is a lot harder.

Now, I've seen amazing things done with processing. It seems really powerful. My other concern is that if I program the GUI in SuperCollider I have to use SuperCollider, while, I think, programming the GUI in another language I can use it with SuperCollider, Pure Data and other languages. Maybe not so easily, but it is a possibility. Am I wrong?

You are right, but that depends on what you do. Stuff like allocating buffers in realtime, changing the signal graph on the fly etc. are quite hard to do with PD and alike, and it seems that your ideas depend on SC provides already. So this is theoretically possible, but you will need to limit your app in functionality for the sake of making a multi-platform compatible GUI. Besides, your SC application can also send osc messages just like processing.

Processing is very powerful, but for certain things. If you are really on the visual sides of things, that is something processing is powerful at. But if you don't need fancy hw accelerated graphics, it is essentially a tool, and don't do much for you by itself. So I think you shouldn't think like "processing is powerful, so it will work for me", instead you should evaluate your programming language candidates based on what you actually want to do. Staying away from sclang will cost you much, you should balance it with something else, I think.

Is there any way to make these languages to interact?

There isn't an easy way I can think of.

Anyway, this is going to be my thesis project, so it is important the research part, the study of the problem and so on. I'm exploring what I can and cannot do.

Thanks for your help :D