Would ChucK be a good roommate?

[MurphS]

Hi,

I've had a couple of vaguely related questions that I have posted here and there and would like to know if ChucK might be able to solve both of these issues. Actually, if he could solve ALL my issues that would be great!

I want to write the software to record (for example), my guitar playing and be able to have it replay the freshly recorded material...while still recording. I'm not out to recreate a looper, rather I would like to be able to combine and layer what I had just played to a ridiculous degree. Details omitted... So all of this playback needs to be triggered by a previously programmed MIDI sequence.

The second issue is with the mixing of all this...I would like to have the mix parameters also to be a part of the same sequence so that when I am playing along with the 15 or however many different parts I had just played and recorded, that the mix would be as I had programmed it to be, then we could all fade out in sync at the end of the song, or whatever.

To summarize: I want to automate the playback and mix of these non-midi streams and have all of this under MIDI control (controlled by a sequence, not necessarily real time control...well, not yet ).

To varying degrees, I have gotten this to work using JAVA, and been very encouraged that I could end up with a valuable program (for me, that is). But the MIDI timing is (infuriatingly) slightly erratic, and at this point I am willing to throw out the baby, the bath water, and anything else nearby.

There are other issues such as the need for a GUI, but there are tons of details I shouldn't go into at this point....however, might it be possible for ChucK to be used as a 'sound engine' behind a JAVA GUI? The possibility of somehow integrating or combining parts of various programs written in different languages was suggested to me, but that's a little over my head at this point...I've got some studying to do...

I am ready to learn any or many languages, if need be, to bring this idea to fruition...even though it's probably already been done. But even if so, that's no big deal, I'd like to be able to do audio programming of this nature anyway.

To my question...does ChucK sound like a good choice for this type of application? Assuming I have done my homework, that is!

Thanks, Scott

[Inventor]

Simple answer Scott: yes. ChucK can do all that stuff. Take a look at the LiSa UGen, it is for Live Sampling, hence the name. Also look at ChucK's MIDI features in the examples. You can link to java with OSC i'd imagine, then make whatever GUI you want in java.

Les

[MurphS]

Thanks, Les... I best get started

-Scott

[MusicMan11712]

[MurphS]

I appreciate your enthusiasm for the project. It seems to me that this is a program which would be a huge success - in that it would become the primary practice and performance tool of many a musician. Especially me! I find it hard to believe that it has not been done already. I've been thinking of making this open-source...I can program so-so, but I think it deserves to be a commercial quality program. I'd be happy to describe the program in more detail, if you are interested.
The way I am thinking right now, I'm not even sure what the actual sequence needs to be running on. Could be a keyboard workstation. That is, if ChucK can receive and respond to midi messages in a timely fashion, then that would be fine. It wouldn't have to be synchronized or anything, just be able to play a particular bit of audio data when it heard the midi message it was waiting for. I haven't yet needed to concern myself with the sizes of data structures... I guess MetaMessages are out of the question? I have been advised that ChucK can work with OSC, could that potentially get around the problem? I only just have found out about this newer protocol. I have much studying to do.
As Les mentioned above, LiSa UGen seems to have all the functionality built in, all I need to do is provoke LiSa every now and then with a midi message and (I think) I'll be good to go.

BTW, what do you think of miniaudicle?

Thanks! Scott

[MusicMan11712]

I'd say it depends how critical timing is in your music. I used my ChucK/Miniaudicle MIDI Router during some live streaming-from-home performances. With too much CC data, ChucK/miniaudicle stopped processing the midi stream and I had to reboot miniaudicle. Timing was not critical in the music I was doing. I would switch midi routings from a usb keyboard and leave notes stuck on until I got back to them, so it was not a major problem.

I have found a problem with miniaudicle on Windows XP--when I exit the application, part of the process remains. I think it has to do with the usb midi device. I learned that turning the usb keyboard off and then on usually clears the miniaudicle process. Sometimes I have also used task manager to terminate the process tree.

I have not gotten around to writing any midi stream thinning routines in chuck (mainly for CC and aftertouch data), but I am hopeful that once I do that there will be less of a problem.

--Steve

[MurphS]

I need impeccable timing (not that I myself am that good ), becasuse the midi sequence is to trigger everything except for my playing...too bad it can't trigger that too. The data streams will pretty much be audio, not midi. So the density of the midi information is so sparse as to be practically non-existent (for what I consider to be the essential function I am trying to implement). One or a group of midi messages delivered once per beat (at whatever tempo), would work nicely. If I further developed mixer functions such as volume adjustments, I would need the midi streams to be denser, but still fairly thin. Of course, audio streams are much denser than the midi, I think...

So I need basically perfect timing, but very little data actually needs to be handled.

ChucK could handle the playing of the sequence, or I could use an external sequencer- then all Chuck would need to do would handle the audio and respond to (the relatively occasional) midi messages. Do you have any idea that would favor one approach over the other? I assume any decent keyboard workstation should be able to play a sequence with acceptable timing.

I haven't learned ChucK yet...do you think I should learn it by itself first before using miniaudicle?


Thanks -Scott

[Kassen]

I think the Mini is the most accessible for prototyping, the commandline version is better once the code is written and the overhead of graphics starts to matter.

I really don't see why ChucK, using Jack on Linux or ASIO on Windows, should have more latency than any sofsynth. I'd go that road, first implement all of the audio and MIDI functionality and based on that see whether you still need a graphical interface. If you have that need I'd consider Processing for that, linked over OSC to ChucK. Processing is meant to make that sort of thing easy and it's based on Java which you already know.


About the MIDI stuff; the functionality of sysex and clock and so on is there in the underlying library, just not implemented in ChucK for reasons I don't quite understand. Sounds to me like that choice might have been made early on when most of the UGens were still STK ones. The STK ones seem to assume MIDI control.