2013/4/22 Kassen
On Sat, Apr 20, 2013 at 09:40:23PM +0200, Philipp Kroos wrote:
Hi! I'm new to this list (and again to ChucK), so hello first ;)
Welcome on board, Phillip!
Thank you! I think my explanation wasn't that clear. In short, I'm looking for the midi-equivalent of the '--out/in' switches to a 'chuck --loop', if that makes sense. Use case: I can run `chuck --loop --out4 --in4` to start sort of a 'server' instance of chuck. That is nice, I can route the ports with jack to other processors or route the output of processors to chuck. If I spork a new shred, the signal flow is already established, i.e., it is possible to hook a new shred into an established signalflow on the fly. I understand this as the purpose of chuck --loop. Now, I'ld like to do the same on the midi-side, but currently, whenever I start a shred that shall process mididata (from a sequencer or to a synth for example), I first have to re-establish the connection, because once the process that opened the midiport dies, the ports are closed. This is very appreciated in the case of a normal process, like you said, but it would be nice if I could just bind them to the bare 'chuck --loop' process. I hope this clarifys my objective. Or maybe I'm missing some concept there yet.. Kind regards, Philipp
Is there a way to keep midiports 'open'? I can specify the number of audio io's when starting chuck --loop, can I do the same with midi io? I'm using LASH on linux. My objective is to start ChucK and connect a midikeyboard to it. In previous versions (used dracula before) a midi-port came up in LASH when I started a .ck-file that used a MidiIn-object, and stayed open. In the current version, the ports disappear once the program finishes.
I'm not sure I understand the question. You would like ChucK to be represented as a sort of virtual MIDI synth even after ChucK has finished?
I could see the use-case but I think I am also opposed to programs that have returned leaving stuff behind. Could you explain a bit about why it wouldn't do to have ChucK open your keyboard straight and release it at termination? If that wouldn't do, would it be enough to have some sort of virtual port that you could route to and that ChuCk could open?
I may not properly understand what you are trying to do and where you run into trouble.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users