(of course its simple for me to use the outputs differently e.g. Two main zones with 3d, then two virtual sliders at each end. I also have limited CV outputs, so 8 cv output + 8 gates, so with 3 dimensions, I divide that into 4 zones. This way I know, when Im in certain areas of the surface I know what voice I’m hitting. So rather than using per touch control for ‘polyphonic’ touch, I use the capabilities for splits. I don’t have (nor want) a large polyphonic eurorack, rather I have a collection of different voices. in the above video you’ll hear the odd ‘quirk’ caused by the VCA behaviour, that just doesn’t exist when I use Veils on the eurorack. If you don’t teak the data, things can be really dependent upon what VCA/filters etc your hitting, e.g. (hmm, really must get the eurorack demo video done!) (The FH-2 can do some slew for you, but that’s one more thing you have to set up.) It can get pretty fussy to get usable results, and there’s a good chance the usable results will compare poorly with the native MPE synths (Equator etc.). And maybe jumpy and steppy, too… you might need to dial in some slew. But when you take that same expressive playing and map its MPE straight to CV on your modular, the results can be quite different. When you use your device with, say, Equator, everything is optimized between the software and the device, so that your expressive playing maps “naturally” to patch parameters. But getting the resulting CV to have a useable response behavior is another story. It’s easy enough to get the FH-2 to provide basic MPE to CV conversion a simple configuration step. It basically works, but I’m also finding it to not be all that compelling. I have an FH-2 and I’ve experimented with it and the Seaboard Block in the past, and I’m currently experimenting with the FH-2 and the Continuumini. So, if I knew which region a note originated from, I’d know which module created it, and could route things appropriately on my end. Joué does send sysex messages identifying when a specific module has been added or removed from each region, and I could totally leverage those. (That’s me, personally, as a developer, not representing the average consumer.) Structuring a set of “devices” based on the three regions you can put a module into would actually solve everything for me. Without suddenly adding OSC support or giving us access to the raw data, we’re limited to channel based module IDs.Īnd actually, yeah. I can forgive that stuff.īut this inability to differentiate which module a signal is coming from is more of a structural problem. Like, if I put aside the controller for a year or two, it should be fine when I get back. Really, I have a litany of fairly major complaints with Joué, each under the header of “they can fix that in software”. This creates unnecessary incentive to consume extra channels, and heightens the problem of only having 16. Supporting poly aftertouch would also help a lot, since right now, MPE is the only way to see pressure data for individual pads. MPE zones is a partial solution, but we can file that next to a dozen other improvements and workarounds they might implement someday. And the only way to know which of those is producing a given signal is by assigning them unique MIDI channels. Short version is, they’ve released twelve separate modules and they’re planning to make more. I suspect is referring to the fact that the Joue frame, could potentially have 2 or 3 different MPE ‘devices’ (Joue is split into 3 separate pads)
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |