fraudulentfromage@gmail.com

I'm about to build an ugly abstract to take care of this, but I feel like

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

[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

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.

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.

special-midiformat-needed-for-vst

>I'm about to build an ugly abstract to take care of this, but I feel 

>[midiformat] is great. It outputs a midi event in its true form, as 

>[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], 

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

>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.
>

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

You may use [thresh] to separate the lists :

f.e chanfrault | aka | personal computer music

> >>>>>> |sublime music for a desperate people|

> I'm about to build an ugly abstract to take care of this, but I feel 

> [midiformat] is great. It outputs a midi event in its true form, as 

> [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 

> ------------------------------------------------------------------------

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
> ------------------------------------------------------------------------
>
>


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.

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

> [midiformat] is great. It outputs a midi event in its true form, as

> 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

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

Powerbook G3/500 640/40 - Stilll great for audio!

Max/MSP, Live 4, DP4, & various hardware synths

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.

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


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

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

alternatively .. hmm .. try to see the controller 

interpretation as a part of the program, an not as 

> 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. :)


> alternatively .. hmm .. try to see the controller

> interpretation as a part of the program, an not as

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.

> 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.

special [midiformat] needed for [vst~]