lfo.midi plugin beta test // and suggestions


    Nov 20 2006 | 4:21 pm
    i've just finished building a beta of a plugin which sends midi controller numbers, like an lfo.
    i figured it was one of those things quite a few ppl are after (including myself) and might aswell have a go at making it. anyway, have got to the point where it seems to work in ableton live 6.01. i've been recording midi CC successfully...
    i have yet to add the sample and hold lfo, and make the parameters automatable (add pp objects).
    in the meanwhile, i invite you to test the plugin / check the source code. below are the issues which hurt my head:
    1. i'm using a signal based lfo > into snapshot set at 1 ms, but at high frequency it is not very accurate... some sort of interpolation / truncation required? is it worth trying to make the lfo sample-accurate or would that be overkill?
    2. pluphasor~ is used to sync to the host, but it seems to be 1/4 note out of phase? this could be related to rate~ which is set to sync lock... but not too sure wot is going on here.
    3. altho i havent noticed it yet, there might also be the old problem of filling the buffer with uzi. think there needs to be a deferlow in there, but can never figure out where? presumably before uzi... (pluggo documentation could do with a bit extra in this department)
    4. out of interest, (i'm curious) how come plugmidiout sends just the controller value, and not a list of number and value (1 64)?
    ez. justin

    • Nov 20 2006 | 4:29 pm
      and here is the vst build (made with pluggo 3.6):
    • Nov 23 2006 | 9:13 am
      >>>>> 1. i'm using a signal based lfo > into snapshot set at 1 ms, but at high frequency it is not very accurate... some sort of interpolation / truncation required? is it worth trying to make the lfo sample-accurate or would that be overkill?
      while it is understandable that you want to throw out vaues as fast as possible, you should not forget that you only send values out in a 7 bit resolution.
      a snapshot at 1 ms will probably cause more dropouts and laggy moments than a snappsnop at 5 ms - would be worth comparing the results.
      or maybe you find a way to only send out values when they are new? your signal LFO would run in a range of 0.-127. and you only filter out new values objects like edge~ or splitters would report if a new value (e.g. "49.") is reached - and that would trigger a number 49 to your midi out stuff.
      >>>> 2. pluphasor~ is used to sync to the host, but it seems to be 1/4 note out of phase? this could be related to rate~ which is set to sync lock... but not too sure wot is going on here.
      those things might be different from host to host (werent there time resolution problems in protools with this object?) but i think you will be able to convert the output from plugphasor to your need, dont you.
      >>> 3. altho i havent noticed it yet, there might also be the old problem of filling the buffer with uzi. think there needs to be a deferlow in there, but can never figure out where? presumably before uzi... (pluggo documentation could do with a bit extra in this department)
      eventually a delay after the loadbang might help. pluggo sometimes seems to hate to much init bangs after startup/load.
      >>> 4. out of interest, (i'm curious) how come plugmidiout sends just the controller value, and not a list of number and value (1 64)?
      plugmidiout will send out what you tell it to ... (not sure if i understand the question ;) )