[chuck-users] midi ports

[Philipp Kroos]

2013/4/22 Kassen <signal.automatique at gmail.com>:
> 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users