Hi

I'm still trying to have split points or keymaps in csound. What I'd 
like to do is have instr x respond to the incomming note on channel 1 if 
it's within a certain range, instr y respond if on channel 1 but whitin 
another range, and so on for at least a handful of "zones", preferrably 
all the way up to 128. And btw: the resulting setup *must* be polyphonic...

I'd also like to select which instrument that responds based on other 
criteria (for instance controllers should prob be send to all), but I 
guess that can easily be added when the basic idea is in place.

I looked at subinstr, but it seems to send score events and I'm 
interrested in sending on the unmodified midi-event (simply directed to 
a specefic midi instrument, based on a certain criteria).

I also looked at midion, but that seems to be sending midi out of csound 
- I want to pass midi to another instrument within the same orchestra.

I also looked at midiin, which seems like a way to investigate the 
incomming midi stream and direct it different places based on criteria. 
But, again, how to activate a certain midi instrument from another midi 
instrument?

I hope someone can guide me in the right direction...

-- 
peace, love & harmony
Atte

http://www.atte.dk

Hey Atte, what I did was have the midi in instrument use table lookup to 
handle keymaps. I declared a bunch of 128 point and 16 point tables in 
the score, and then the parser looks up the corresponding note out 
values before sending off score events with the event opcode. This means 
it's easy to add real time controls changing how this midi parsing is 
controlled, and you can easily add velocity mapping too.

Now, all this said, I use monosynths so it's a bit easier to handle note 
offs because instead of turning a note off, the noisemaking instrument 
just stays on all the time, and a note off gets remapped to an event 
that starts the release envelope in the noisemaker. This envelope closes 
to amplitude darn close to zero, but keeps the instrument on. So there 
would need to be some additional hackery to handle poly synths I think.

Iain

Atte André Jensen wrote:
> Hi
> 
> I'm still trying to have split points or keymaps in csound. What I'd 
> like to do is have instr x respond to the incomming note on channel 1 if 
> it's within a certain range, instr y respond if on channel 1 but whitin 
> another range, and so on for at least a handful of "zones", preferrably 
> all the way up to 128. And btw: the resulting setup *must* be polyphonic...
> 
> I'd also like to select which instrument that responds based on other 
> criteria (for instance controllers should prob be send to all), but I 
> guess that can easily be added when the basic idea is in place.
> 
> I looked at subinstr, but it seems to send score events and I'm 
> interrested in sending on the unmodified midi-event (simply directed to 
> a specefic midi instrument, based on a certain criteria).
> 
> I also looked at midion, but that seems to be sending midi out of csound 
> - I want to pass midi to another instrument within the same orchestra.
> 
> I also looked at midiin, which seems like a way to investigate the 
> incomming midi stream and direct it different places based on criteria. 
> But, again, how to activate a certain midi instrument from another midi 
> instrument?
> 
> I hope someone can guide me in the right direction...
> 

Iain Duncan wrote:

> Hey Atte, what I did was have the midi in instrument use table lookup to 
> handle keymaps. I declared a bunch of 128 point and 16 point tables in 
> the score, and then the parser looks up the corresponding note out 
> values before sending off score events with the event opcode. This means 
> it's easy to add real time controls changing how this midi parsing is 
> controlled, and you can easily add velocity mapping too.
> 
> Now, all this said, I use monosynths so it's a bit easier to handle note 
> offs because instead of turning a note off, the noisemaking instrument 
> just stays on all the time, and a note off gets remapped to an event 
> that starts the release envelope in the noisemaker. This envelope closes 
> to amplitude darn close to zero, but keeps the instrument on. So there 
> would need to be some additional hackery to handle poly synths I think.

So what you're saying is that there's no way of reading the input stream 
and altering it in some way?

If this is the approach, I can see why you're thinking of doing it 
externally.

Actually I'll make a quick stab at doing it in python (using pyseq). 
It's quite simple, the only drawback would be that I have to 1) start 
the splitter 2) attach keyboards to splitter 3) attach splitter to midi 
through and 4) start csound having it read from midi through. Bash to 
the rescue :-)

-- 
peace, love & harmony
Atte

http://www.atte.dk

>> Hey Atte, what I did was have the midi in instrument use table lookup 
>> to handle keymaps. I declared a bunch of 128 point and 16 point tables 
>> in the score, and then the parser looks up the corresponding note out 
>> values before sending off score events with the event opcode. This 
>> means it's easy to add real time controls changing how this midi 
>> parsing is controlled, and you can easily add velocity mapping too.
>>
>> Now, all this said, I use monosynths so it's a bit easier to handle 
>> note offs because instead of turning a note off, the noisemaking 
>> instrument just stays on all the time, and a note off gets remapped to 
>> an event that starts the release envelope in the noisemaker. This 
>> envelope closes to amplitude darn close to zero, but keeps the 
>> instrument on. So there would need to be some additional hackery to 
>> handle poly synths I think.
> 
> 
> So what you're saying is that there's no way of reading the input stream 
> and altering it in some way?

Well, it all depends how you want to handle events. Personally, I found 
converting midi input to csound score events to be more flexible than 
just rerouting midi anyway. You can thus have any instrument triggering 
any instrument in the same fashion to do midi delays, doubling, 
whatever. After mucking with both approaches, I've settled on all 
internal triggering with score events. YMMV = )

the reason I want to handle midi input externally is because:
- I want multiple midi in ports
- I want other input devices to be handled in a similar fashion through 
the same parser ( keystrokes, custom serial gak, etc )
- I want to be able to use higher language constructs ( C++ or Python ) 
for handling complicated midi parsing
- I want some midi events to control csound, and some to control my host 
app ( which also handles the gui, file i/o, etc ).

iain