[chuck-users] midi ports
philipp.kroos at gmail.com
Tue Apr 23 16:37:39 EDT 2013
2013/4/22 Kassen <signal.automatique at gmail.com>:
> On Sat, Apr 20, 2013 at 09:40:23PM +0200, Philipp Kroos wrote:
>> I'm new to this list (and again to ChucK), so hello first ;)
> Welcome on board, Phillip!
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.
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..
>> 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
> 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.
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users