Hi! I'm new to this list (and again to ChucK), so hello first ;) 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. Thanks for any hints! - Philipp
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!
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.
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
On Tue, Apr 23, 2013 at 10:37:39PM +0200, Philipp Kroos wrote:
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.
A bit, yes. Do I understand correctly that the core of your issue is that you would like to set the MIDI routing from outside of ChucK instead of from inside the code itself? Personally I so far think that the current behaviour is desirable and that MIDI is more flexible to work with than audio from this perspective. Audio reservations need to be made at the start of the VM because those dictate at what speed the UGens will be running and how long a "samp" is. For that reason we can't open and close ADC's and DAC's as we please. I think you were also saying that the behaviour here changed with a recent version, though I can't remember that being a documented change. I now wonder what is up there; maybe we accidentally have some sort of issue. What you could try is run some code that creates a MIDI port as a static member of a public class when you start your VM and have shreds interact with that instead of opening their own ports. That way the port should be and stay open as long as the VM lives. I never tried that myself but I don't see why it wouldn't work. Hope that clarifies things a bit and gets you a bit further. Yours, Kas.
participants (2)
-
Kassen
-
Philipp Kroos