2013/4/22 Kassen <[email protected]>: > 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 > [email protected] > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users _______________________________________________ chuck-users mailing list [email protected] https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
