Vienna Symphonic Library Forum
Forum Statistics

180,297 users have contributed to 42,114 threads and 254,247 posts.

In the past 24 hours, we have 1 new thread(s), 7 new post(s) and 71 new user(s).

  • Ableton and VEP: Where Are the Midi PORTS

    Paging Paul.... 

     

    anybody know where in Ableton Live I can go to change the MIDI Port number? Not the MIDI channels (1 - 16), but the MIDI Port channel (1 - 8)


  • Hi, 

    AFAIK, Ableton Live does not support VST 3, so you only have one MIDI Port, I'm afraid. 

    Best, 
    Paul


    Paul Kopf Product Manager VSL
  • ah shucks. oh well.

    thanks paul!


  • last edited
    last edited

    @Paul said:

    Hi, 

    AFAIK, Ableton Live does not support VST 3, so you only have one MIDI Port, I'm afraid. 

    Best, 
    Paul

    Actually, Ableton 10 supports VST 3, but there doesn't seem to be a way in Live to reroute to a particular port on output.  Live depends on published ports being made available to the application.  Without getting into the specifics of their model, the VEPro plugin really should offer rerouting akin to what is available in the VEPro Event plugin, but I'd recommend VSL add midi channel selection to that as well.

    Right now the stalemate is pretty effing irritating, and I'm not relishing switching back to another DAW for this.

    Sincerely,
    Daniel


  • p.s.  Yeah, it looks like there is no substantive difference between the VST and the VST3 versions of the plugin.  It's a shame.  I'd really really like to keep instruments in a single track without having to hack around the design limitations.


  • Hi, 

    I have requested the extension for multiple MIDI Ports for VST 3 in the Ableton Beta Forum a few times. Should not be very hard to achieve.... maybe Ableton needs a little push from enough users ;-)

    Best,
    Paul


    Paul Kopf Product Manager VSL
  • Thank you for the speedy response, Paul. With all due respect, and speaking as a developer with thirty years professional experience, I believe it’s going to be much easier for the VEPro plugin developers to provide port and channel parameters into their custom protocols. The industry has moved away from channels and ports for usability reasons. Vienna can ignore the Ableton paradigm if they want to, but at this point I feel like I’ve been sold a load of goods I cannot use, for no particularly good reason. I will continue to lobby Ableton as well, but to be clear, in this case I feel that’s an extremely long way around inadequate plugin design, crippling the operation of an industry standard product. Alternatively, Vienna might look at making instances lighter weight and organizable as channels are now. But again, that’s a huge paradigm shift where someone in the plugin department could just sit down with a copy of Live for a day and realize what they should have considered already. Add a port and channel field to the plugin and relieve our collective headaches. Kind regards, Daniel

  • Unfortunately it isn't as easy as setting a "port per plug-in", since each plug-in (and instance) may live within its own processing chain - different threads, different blocksizes. 

    In fact, the "Event input" plug-in already does what you want, but it also comes with a whole array of  drawbacks when used in a host that handles playback and recording tracks differently.

    EDIT: The event input plug-in doesn't allow filtering channels, only ports.


  • last edited
    last edited

    @MS said:

    Unfortunately it isn't as easy as setting a "port per plug-in", since each plug-in (and instance) may live within its own processing chain - different threads, different blocksizes. 

    In fact, the "Event input" plug-in already does what you want, but it also comes with a whole array of  drawbacks when used in a host that handles playback and recording tracks differently.

    EDIT: The event input plug-in doesn't allow filtering channels, only ports.

    Thanks for your interest in this matter, Martin.

    Regarding the former, as expected, not trivial, albeit abstracting away from the literal meaning of ports, I still think it's worth considering.  As for the latter, yes, your "edit" reveals what led to my posting here.

    Neither Ableton or Vienna is really losing, at least as far as I'm concerned, as it's forcing me to crossgrade to Cubase for expression mapping.  Just an expensive and annoying bump in the road where the opportunity to improve on an otherwise already great product is concerned.  I'll end up using all three.  But that said, seems like folks on several DAW platforms are hacking around things that Vienna could provide.  It's the drug of a great product.  If most people think the programs do everything well already, it's hard to gain leverage towards improvement.

    I wish you luck on any changes made moving forward.  Suffice it to say, I imagine that in any DAW, uniting midi routing out the send with graceful return of audio into a single track is going to make loads of people happier.

    Kind regards,
    Daniel


  • last edited
    last edited

    @rockstarjazzcat said:

    I wish you luck on any changes made moving forward.  Suffice it to say, I imagine that in any DAW, uniting midi routing out the send with graceful return of audio into a single track is going to make loads of people happier.

    Exactly this is what is close to impossible to achieve today, and getting more and more difficult to achieve as time goes by. DAWs have kept moving in the direction of each plug-in being processed in its own little time- and buffer world, and synchronizing between plug-in instances has become incredibly difficult. Some hosts even completely pre-process certain tracks way ahead of time.

    Consider this possible scenario:
    - One plugin for MIDI events
    - One plugin for audio return

    The audio return plugin is buffered, and processed 30 seconds ahead of time. The midi plug-in is selected for recording, and is processed in realtime.


  • So given the challenges that abound, maybe add that missing channel selector to the VST3 event plugin?

    Thank you, Martin.

    Kind regards,

    Daniel