special [midiformat] needed for [vst~]

Aug 3, 2006 at 6:06am

special [midiformat] needed for [vst~]

I’m about to build an ugly abstract to take care of this, but I feel like
complaining anyway.

[midiformat] is great. It outputs a midi event in its true form, as several
successive integers. cool.

[vst~] takes the message |midievent $1 $2 $3|

The problem is that to turn [midiformat]‘s output into something usable for
[vst~], you have to group the successive integer outputs from [midiformat]
into a list. Easy enough with [zl group 3] in the case of notes, but what
about pgm change? That’s only 2 integers out of [midiformat]! [zl group]
messes everything up if it gets 2 integers when its looking for 3! [thresh]
could work, but it’s too slow separate the notes when chords are played!

For this case, we need an object that acts just like [midiformat], but
outputs lists.

cheese

#27023
Aug 3, 2006 at 6:48am

>I’m about to build an ugly abstract to take care of this, but I feel
>like complaining anyway.
>
>[midiformat] is great. It outputs a midi event in its true form, as
>several successive integers. cool.
>
>[vst~] takes the message |midievent $1 $2 $3|
>
>The problem is that to turn [midiformat]‘s output into something
>usable for [vst~], you have to group the successive integer outputs
>from [midiformat] into a list. Easy enough with [zl group 3] in the
>case of notes, but what about pgm change? That’s only 2 integers out
>of [midiformat]! [zl group] messes everything up if it gets 2
>integers when its looking for 3! [thresh] could work, but it’s too
>slow separate the notes when chords are played!
>
>For this case, we need an object that acts just like [midiformat],
>but outputs lists.
>

or just make your lists of integers ( 2 or 3) and [prepend midiformat]?

should work, i think

kasper

Kasper T. Toeplitz
noise, composition, bass, computer

http://www.sleazeArt.com

#81384
Aug 3, 2006 at 7:41am

You may use [thresh] to separate the lists :

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 106 96 40 9109513 sel 0 1;
#P toggle 106 75 15 0;
#P newex 106 225 26 9109513 print;
#P message 202 130 13 9109513 3;
#P comment 217 131 78 9109513 Program change;
#P comment 143 130 42 9109513 Note On;
#P message 106 129 34 9109513 60 64;
#P toggle 106 16 15 0;
#P newex 106 48 50 9109513 metro 100;
#P newex 106 159 207 9109513 midiformat;
#P newex 106 196 34 9109513 thresh;
#P connect 10 1 7 0;
#P connect 10 0 4 0;
#P connect 9 0 10 0;
#P connect 2 0 9 0;
#P connect 0 0 8 0;
#P connect 7 0 1 3;
#P connect 4 0 1 0;
#P connect 3 0 2 0;
#P connect 1 0 0 0;
#P window clipboard copycount 11;

f.e

f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|

cheese wrote:
> I’m about to build an ugly abstract to take care of this, but I feel
> like complaining anyway.
>
> [midiformat] is great. It outputs a midi event in its true form, as
> several successive integers. cool.
>
> [vst~] takes the message |midievent $1 $2 $3|
>
> The problem is that to turn [midiformat]‘s output into something
> usable for [vst~], you have to group the successive integer outputs
> from [midiformat] into a list. Easy enough with [zl group 3] in the
> case of notes, but what about pgm change? That’s only 2 integers out
> of [midiformat]! [zl group] messes everything up if it gets 2
> integers when its looking for 3! [thresh] could work, but it’s too
> slow separate the notes when chords are played!
>
> For this case, we need an object that acts just like [midiformat], but
> outputs lists.
>
>
> cheese
> ————————————————————————
>
>

#81385
Aug 3, 2006 at 7:46am

OK, the abstract took less time than the email. It’s just a wrapper for
[midiformat] with a right outlet that outputs the MIDI event as a list.

cheese

max v2;
#N vpatcher 58 53 846 540;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 93 291 25 196617 iter;
#N comlet (list) MIDI Message Output;
#P outlet 212 337 15 0;
#N comlet MIDI Message Output;
#P outlet 93 337 15 0;
#P newex 212 269 46 196617 zl group;
#P newex 72 95 29 196617 t l 3;
#P newex 113 95 29 196617 t l 3;
#P newex 149 95 29 196617 t l 3;
#P newex 269 95 29 196617 t i 3;
#P newex 227 95 29 196617 t i 2;
#P newex 188 95 29 196617 t i 2;
#N comlet Set MIDI Channel;
#P inlet 332 65 15 0;
#N comlet Pitch Bend;
#P inlet 272 65 15 0;
#N comlet After Touch;
#P inlet 227 65 15 0;
#N comlet Program Change;
#P inlet 197 65 15 0;
#N comlet Control Change (list: Controller Number , Value);
#P inlet 154 65 15 0;
#N comlet Poly Key Pressure (list: Key , Value);
#P inlet 113 65 15 0;
#N comlet Note-on or Note-off (list: Pitch , Velocity);
#P inlet 72 65 15 0;
#P newex 93 234 92 196617 midiformat $1;
#B color 5;
#P connect 1 0 13 0;
#P connect 13 0 0 0;
#P connect 14 0 17 0;
#P connect 17 0 15 0;
#P connect 12 0 0 1;
#P connect 2 0 12 0;
#P connect 11 0 0 2;
#P connect 8 0 0 3;
#P connect 9 0 0 4;
#P connect 3 0 11 0;
#P connect 10 0 0 5;
#P connect 7 0 0 6;
#P connect 4 0 8 0;
#P connect 0 0 14 0;
#P connect 14 0 16 0;
#P connect 5 0 9 0;
#P connect 10 1 14 1;
#P connect 9 1 14 1;
#P connect 8 1 14 1;
#P connect 11 1 14 1;
#P connect 12 1 14 1;
#P connect 13 1 14 1;
#P connect 6 0 10 0;
#P pop;

On 8/2/06, cheese < fraudulentfromage@gmail.com> wrote:
>
> I’m about to build an ugly abstract to take care of this, but I feel like
> complaining anyway.
>
> [midiformat] is great. It outputs a midi event in its true form, as
> several successive integers. cool.
>
> [vst~] takes the message |midievent $1 $2 $3|
>
> The problem is that to turn [midiformat]‘s output into something usable
> for [vst~], you have to group the successive integer outputs from
> [midiformat] into a list. Easy enough with [zl group 3] in the case of
> notes, but what about pgm change? That’s only 2 integers out of
> [midiformat]! [zl group] messes everything up if it gets 2 integers when its
> looking for 3! [thresh] could work, but it’s too slow separate the notes
> when chords are played!
>
> For this case, we need an object that acts just like [midiformat], but
> outputs lists.
>
>
> cheese
>

———————
Powerbook G3/500 640/40 – Stilll great for audio!
Max/MSP, Live 4, DP4, & various hardware synths

#81386
Aug 3, 2006 at 1:14pm

> or just make your lists of integers ( 2 or 3) and [prepend midiformat]?
>
> should work, i think
>
> kasper

thats true, just _abuse midiformat and it will work
like you want. the objetcs knowsn nothing about midi,
it simply performs a certain formatting on the input
given.

alternatively .. hmm .. try to see the controller
interpretation as a part of the program, an not as
a part of plug-in hosting. :)

#81387
Aug 3, 2006 at 6:47pm

> alternatively .. hmm .. try to see the controller
> interpretation as a part of the program, an not as
> a part of plug-in hosting. :)

That was where I came from! I’m not entirely sure that it was a good idea to
switch to using midi internally in my patch, but it uses far fewer objects
than my “proprietary” protocol that I switched from. Midi is easier for the
routing of events to multiple devices, and it’s nice to just be able to
stick all the different events into [midiformat] and into a bus.

What do others use internally?

cheese

#81388

You must be logged in to reply to this topic.