i am attempting my first max4live creation, a handler for my roland td20 drum set, and i'm noticing a very disappointing (lack of a) feature in live -- i am unable to send the poly aftertouch from the drums through live to the max device! the roland kit sends the cymbal choke trigger signal via poly aftertouch, corresponding to the note triggers for the bell/bow/edge on the cymbals.
is this really true? is live, at a very mature and sprawling version 8, not capable of receiving aftertouch? based on my findings in this forum, it appears to be the truth.
i can even accept live itself not utilizing the aftertouch data, but now that max4live has been introduced, this seems like a very glaring omission -- we should at least be able to pass the aftertouch through live into max. there are lots of different expressive digital instruments, custom controllers and devices, and plenty of other oddball reasons that people would have for sending aftertouch data into max4live.
thoughts? workarounds? am i incorrect in my findings? please please, ableton, whilst you are making an effort to mend live's current shortcomings, please address this.
No Poly Aftertouch? Really?
Re: No Poly Aftertouch? Really?
create a max patch with m4l and open it with max runtime
have that max patch intercept the midi and change the aftertouch into CCs
then send it to ableton
or
intercept it the send it to live over osc to a m4l patch
have that max patch intercept the midi and change the aftertouch into CCs
then send it to ableton
or
intercept it the send it to live over osc to a m4l patch
-
muchachotron
- Posts: 43
- Joined: Sat Sep 08, 2007 6:33 am
Re: No Poly Aftertouch? Really?
thanks, zalo, i will give that a go.
have you used this for the same workaround? i feel like it could cause latency issues, but i don't really need the aftertouch to be extremely responsive in this case since it's just for the choke/mute on the cymbals (though the other triggers need to be as speedy as possible). i haven't yet found a control on the roland brain to change the aftertouch to some other signal type, so it seems i must handle the conversion on the computer.
have you used this for the same workaround? i feel like it could cause latency issues, but i don't really need the aftertouch to be extremely responsive in this case since it's just for the choke/mute on the cymbals (though the other triggers need to be as speedy as possible). i haven't yet found a control on the roland brain to change the aftertouch to some other signal type, so it seems i must handle the conversion on the computer.
Re: No Poly Aftertouch? Really?
possibly it would cause some latency, but luckily ableton disregards the poly aftertouch
the triggers can be sent on the original channel (no added latency) and the converted after touch over OSC (this would be a small patch, and relatively low latency)
the triggers can be sent on the original channel (no added latency) and the converted after touch over OSC (this would be a small patch, and relatively low latency)
-
muchachotron
- Posts: 43
- Joined: Sat Sep 08, 2007 6:33 am
Re: No Poly Aftertouch? Really?
in the max for live documentation, "max for live for pluggo developers":
"Live does not currently support polyphonic aftertouch (received by the polyin~ object)."
gosh, that sucks.
"Live does not currently support polyphonic aftertouch (received by the polyin~ object)."
gosh, that sucks.
Re: No Poly Aftertouch? Really?
the various limitations of Live's MIDI are the reason that I've avoided M4L to this point. It doesn't seem consistent to pair something as dependent on a solid and complete MIDI implementation as Max, with a relatively bare-bones MIDI sequencer like Live. Even the timing problem that Live has (incoming MIDI data isn't recorded in proper alignment with audio data) seems like a pain if you're going to use Max for intricate stuff.
Re: No Poly Aftertouch? Really?
It is a shoddy implementation. I got rid of most of my hardware and the stuff I have now is so freaky it needs to be recorded as audio anyway but I used to have an all hardware studio and I would fairly often use sysex to get at parameters in sound and effects modules. I think the Roland synths use Sysex (or maybe NRPN's) as well.
Re: No Poly Aftertouch? Really?
I wouldn't call it a 'shoddy' implementation, but rather simplification/restriction by design.
http://en.wikipedia.org/wiki/KISS_principle
http://en.wikipedia.org/wiki/KISS_principle
Re: No Poly Aftertouch? Really?
no...it's not that.broc wrote:I wouldn't call it a 'shoddy' implementation, but rather simplification/restriction by design.
http://en.wikipedia.org/wiki/KISS_principle
-
muchachotron
- Posts: 43
- Joined: Sat Sep 08, 2007 6:33 am
Re: No Poly Aftertouch? Really?
after doing some more research, here's what i think this boils down to:
handling of the poly aftertouch data used to be computationally expensive, both for the midi bandwidth limitations and for the multiple streams of constantly-shifting data (for example, 10 fingers, squeezing down on the keys, light-to-heavy-to-light in a rhythmic pattern, sending ramps of poly aftertouch midi data all at once, constantly until the keys are released w/ a note off message). i honestly don't know if poly aftertouch processing should be easier or not these days, but i'm afraid it may just be a legacy oversight that ableton may not care to address, since poly aftertouch from factory controllers is not only possibly complex/latency-inducing, but also not very common, and becoming even less so -- usually a 'board with an "aftertouch!" marketing point is referring to channel pressure, which is indeed more common and simpler to parse, as all keys will transmit the same info.
the poly a.t. from the td20 is actually pretty simple, its just a 0 and a 127, choke on or off from the various cymbal sensors (no ramps or constant streams), so i'm quite sure live could pass it through easily if ableton chose to implement the handling of the data. in the end, i just hope ableton moves to allow all incoming midi to just pass through into m4l, whether or not live itself is designed to utilize the data. maybe once m4l is invoked, live can "bridge" incoming midi to m4l devices, before live even knows what hits it. hope hope.
handling of the poly aftertouch data used to be computationally expensive, both for the midi bandwidth limitations and for the multiple streams of constantly-shifting data (for example, 10 fingers, squeezing down on the keys, light-to-heavy-to-light in a rhythmic pattern, sending ramps of poly aftertouch midi data all at once, constantly until the keys are released w/ a note off message). i honestly don't know if poly aftertouch processing should be easier or not these days, but i'm afraid it may just be a legacy oversight that ableton may not care to address, since poly aftertouch from factory controllers is not only possibly complex/latency-inducing, but also not very common, and becoming even less so -- usually a 'board with an "aftertouch!" marketing point is referring to channel pressure, which is indeed more common and simpler to parse, as all keys will transmit the same info.
the poly a.t. from the td20 is actually pretty simple, its just a 0 and a 127, choke on or off from the various cymbal sensors (no ramps or constant streams), so i'm quite sure live could pass it through easily if ableton chose to implement the handling of the data. in the end, i just hope ableton moves to allow all incoming midi to just pass through into m4l, whether or not live itself is designed to utilize the data. maybe once m4l is invoked, live can "bridge" incoming midi to m4l devices, before live even knows what hits it. hope hope.
Re: No Poly Aftertouch? Really?
..seems funny as 'operator'/'sampler' support aftertouch...(don't know if poly or not)muchachotron wrote:after doing some more research, here's what i think this boils down to:
handling of the poly aftertouch data used to be computationally expensive, both for the midi bandwidth limitations and for the multiple streams of constantly-shifting data (for example, 10 fingers, squeezing down on the keys, light-to-heavy-to-light in a rhythmic pattern, sending ramps of poly aftertouch midi data all at once, constantly until the keys are released w/ a note off message). i honestly don't know if poly aftertouch processing should be easier or not these days, but i'm afraid it may just be a legacy oversight that ableton may not care to address, since poly aftertouch from factory controllers is not only possibly complex/latency-inducing, but also not very common, and becoming even less so -- usually a 'board with an "aftertouch!" marketing point is referring to channel pressure, which is indeed more common and simpler to parse, as all keys will transmit the same info.
the poly a.t. from the td20 is actually pretty simple, its just a 0 and a 127, choke on or off from the various cymbal sensors (no ramps or constant streams), so i'm quite sure live could pass it through easily if ableton chose to implement the handling of the data. hope hope.
and many other vsti's as well..
so you know aftertouch is getting in ...
one of the many weird things ..
-
muchachotron
- Posts: 43
- Joined: Sat Sep 08, 2007 6:33 am
Re: No Poly Aftertouch? Really?
yeah, 3dot. i got excited about that too, but it's referring to channel pressure a.t., not poly. granted, this is cool and i have no complaints that at least this is supported. i have a novation keyboard that sends the mono/pressure aftertouch on the keys and that works.
the mono a.t. is interpreted the same across all incoming notes, no matter which key/octave/pad, etc. you send the aftertouch on. for example, all keys will transmit "channel pressure" (0-127) on channel 1, where poly is able to send that info, but individually, per note.
the polyphonic aftertouch, specifically, is stated to be unsupported. really, i'm afraid i may be overstating the lack of poly support in live -- i really don't know how common it is across different software. within live itself, new live instruments (or at least serious updates to the code) would probably have to be developed in order to map the aftertouch and utilize it well. just on a single keyboard controller, you could think of it as having 127 extra knobs/faders on the controller (reduced to the physical amount of keys, of course), to be mapped or otherwise processed as controller data. i FEEL like live should be capable of that on a modern machine, but maybe it is not a good idea?
the mono a.t. is interpreted the same across all incoming notes, no matter which key/octave/pad, etc. you send the aftertouch on. for example, all keys will transmit "channel pressure" (0-127) on channel 1, where poly is able to send that info, but individually, per note.
the polyphonic aftertouch, specifically, is stated to be unsupported. really, i'm afraid i may be overstating the lack of poly support in live -- i really don't know how common it is across different software. within live itself, new live instruments (or at least serious updates to the code) would probably have to be developed in order to map the aftertouch and utilize it well. just on a single keyboard controller, you could think of it as having 127 extra knobs/faders on the controller (reduced to the physical amount of keys, of course), to be mapped or otherwise processed as controller data. i FEEL like live should be capable of that on a modern machine, but maybe it is not a good idea?
Re: No Poly Aftertouch? Really?
maybe you could switch it ? on/off..?muchachotron wrote:yeah, 3dot. i got excited about that too, but it's referring to channel pressure a.t., not poly. granted, this is cool and i have no complaints that at least this is supported. i have a novation keyboard that sends the mono/pressure aftertouch on the keys and that works.
the mono a.t. is interpreted the same across all incoming notes, no matter which key/octave/pad, etc. you send the aftertouch on. for example, all keys will transmit "channel pressure" (0-127) on channel 1, where poly is able to send that info, but individually, per note.
the polyphonic aftertouch, specifically, is stated to be unsupported. really, i'm afraid i may be overstating the lack of poly support in live -- i really don't know how common it is across different software. within live itself, new live instruments (or at least serious updates to the code) would probably have to be developed in order to map the aftertouch and utilize it well. just on a single keyboard controller, you could think of it as having 127 extra knobs/faders on the controller (reduced to the physical amount of keys, of course), to be mapped or otherwise processed as controller data. i FEEL like live should be capable of that on a modern machine, but maybe it is not a good idea?
that would be swell
-
timeline85
- Posts: 54
- Joined: Thu May 01, 2008 9:06 am
Re: No Poly Aftertouch? Really?
PolyAT is identical in data structure to CC events. Eight fingers all sending PolyAT would be the same as eight fingers on sliders controlling CCs. The only difference would be if a noteoff event occurs for a note that was sending polyAT, then you would need to set the polyAT value to 0. This would only be necessary if the controller itself didn't do this (and it should if it's been programmed correctly).
I honestly can't understand why ableton a) doesn't support it, or b) doesn't at least let it pass through. You can't even send a polyAT message from a controller through ableton out a MIDI port, it just filters it out.
You could seriously just copy the code in ableton that handles CC events, rename it the PolyAT subroutine, and change which status byte the code responds to from CC (1011xxxx) to PolyAT (1010xxxx). Then when editing a MIDI clip, have a separate envelope drop down menu for PolyAT.
Yes this isn't a hugely sought after feature, but we're talking maybe a week of coding time tops for a single programmer.
Or hey, go into the code where you recognize the (1010xxxx) status byte and instead of ignoring it, let it pass through. I bet that would take an ableton programmer 10 minutes to do.
If you think I'm just talking out of turn, check out my work at www.colorsynth.com. I've programmed microcontrollers to recognize the entire MIDI spec, using only assembly. This isn't rocket science.
I honestly can't understand why ableton a) doesn't support it, or b) doesn't at least let it pass through. You can't even send a polyAT message from a controller through ableton out a MIDI port, it just filters it out.
You could seriously just copy the code in ableton that handles CC events, rename it the PolyAT subroutine, and change which status byte the code responds to from CC (1011xxxx) to PolyAT (1010xxxx). Then when editing a MIDI clip, have a separate envelope drop down menu for PolyAT.
Yes this isn't a hugely sought after feature, but we're talking maybe a week of coding time tops for a single programmer.
Or hey, go into the code where you recognize the (1010xxxx) status byte and instead of ignoring it, let it pass through. I bet that would take an ableton programmer 10 minutes to do.
If you think I'm just talking out of turn, check out my work at www.colorsynth.com. I've programmed microcontrollers to recognize the entire MIDI spec, using only assembly. This isn't rocket science.