Jump to content

Possible 10.4 Scripter bugs...


Dewdman42

Recommended Posts

I'd like to use this thread to discuss possible bugs or changes that have possibly been introduced to LPX 10.4.

 

I have noticed a couple weird behaviors so far...

 

  1. I put two instances of Scripter in series on a track and then worked on both scripts for a while. When I removed the second plugin instance, the script in the first instance was reverted back to a much older version of the actual script. This happened several times. huh?
  2. Now I am noticing that every time the Run Script button is hit, the script UI shrinks down to a size that is too small to even show all the controls. Super annoying.
  3. An undocumented feature used to exist that allegedly allowed this:
       PluginParameters.push({
        name: "Logging",
        type: "checkbox",
        defaultValue: 1,
        data:1,
        disableAutomation: true,
        hidden: false
      });
      


     
    Note the disableAutomation flag, which allegedly would hide/show UI fields from LPX automation. This appears to have no effect now, all Script UI controls are now accessible from automation no matter what, and because of the way LPX has been redesigned in 10.4 to make automation so much easier in the piano roll, its also very easy to accidentally click on the piano roll automation area and accidentally create automation events which change the Script UI when you're not looking.

 

That's it for now, but curious if anyone else is running into any other oddities with 10.4 Scripter.

Link to comment
Share on other sites

I'd like to use this thread to discuss possible bugs or changes that have possibly been introduced to LPX 10.4.

 

I have noticed a couple weird behaviors so far...

 

  1. I put two instances of Scripter in series on a track and then worked on both scripts for a while. When I removed the second plugin instance, the script in the first instance was reverted back to a much older version of the actual script. This happened several times. huh?
  2. Now I am noticing that every time the Run Script button is hit, the script UI shrinks down to a size that is too small to even show all the controls. Super annoying.
  3. An undocumented feature used to exist that allegedly allowed this:
       PluginParameters.push({
        name: "Logging",
        type: "checkbox",
        defaultValue: 1,
        data:1,
        disableAutomation: true,
        hidden: false
      });
      


     
    Note the disableAutomation flag, which allegedly would hide/show UI fields from LPX automation. This appears to have no effect now, all Script UI controls are now accessible from automation no matter what, and because of the way LPX has been redesigned in 10.4 to make automation so much easier in the piano roll, its also very easy to accidentally click on the piano roll automation area and accidentally create automation events which change the Script UI when you're not looking.

 

That's it for now, but curious if anyone else is running into any other oddities with 10.4 Scripter.

 

#1 Are you saving your scripts prior to unloading them. I do this every time I make changes. Get in a habit of doing this and you won't lose any changes. I unloaded a second script and the first script had my last changes that I saved.

#2. Yes UI goes smaller.

#3. This isn't a bug since it's undocumented. Developers should stay away from undocumented anything because of what you're seeing with this disableAutomation in that now it doesn't work. Here today, gone tomorrow. Stay away from undocumented. :)

Link to comment
Share on other sites

found another Scripter bug. I have a script on channel 1. Its doing stuff. Seems to work good. However, somehow when that script is active, the click channel drops clicks in and out erratically. Disabling scripter on the instrument channel restores normal metronome and enabling it again brings back the click-dropping over on the click channel.

 

This does not occur with the default simple script, my script is quite complicated, and it functions perfectly on its own track, so impossible for me to identify what exactly in the script would be causing that to happen.

 

Other specifics about the situation, using Kontakt in multi-timbral mode with 7 aux outputs from it. So perhaps its related to the way multi-timbral mode through AUX track regions shuttles midi around under the covers. not sure.

Link to comment
Share on other sites

To add to the previous bug report... This problem shows up, when using multi-timbral kontakt in the method where midi regions are directly on the AUX tracks. But more interestingly, the problem shows up when one of those tracks or the actual 1st inst track are selected. If I create an additional empty track and select that one BEFORE hitting play, then everything works correctly and normally, the script is doing whatever it does and click sounds. I also note that when one of the aux tracks or the inst track are selected, I easily start getting drop outs and stuff happening, but if the empty track is selected I don't.

 

So this leads me to believe the bug might be related to the little trick of putting midi regions on aux tracks, which is funneling midi data through to the instrument channel that is hosting both kontakt as well as my Scripter script. I think something under the covers is doing automagic stuff...and somehow mungling up the midi between that and the click track, which should be isolated from it, but somehow isn't.

 

My script works no problems at all if I use seperate instance of kontakt for each track (no aux regions), or if I use the multi-timbral method created by new track wizard, where n number of tracks are pointing directly to one instrument channel..in that case the midi regions are NOT on the aux tracks..they are on their own tracks and directly patched to the instrument.. that seems to work ok too.

 

I don't want to share my script here, but if someone wants to try to replicate this for me, please PM. Mainly its just sending keyswitches..but I think the keyswitches are interfering with the metronome instrument when using the AUX track multi-timbral method.

Link to comment
Share on other sites

  • 3 months later...

MIDI event does not contain the articulationID information if Logic's own Articulation Set is used. If the Articulation Set is set to none, then articulationID is again present in the event.

 

This is annoying, since the Logic's own Articulation system is not 100% accurate (for example, if CC commands are sent _after_ the NoteOn has been processed, it will skip the articulation change for the instrument that is expecting CC before NoteOn) and I have a MIDI scripter that could use articulationID to send the CC before NoteOn, but I'd like to see the articulation names instead of numbers.

 

So currently it's either proper articulation names with random behaviour, or 100% working articulations but I need to remember which number is which articulation.

 

EDIT: It seems that removing the articulation from the Output section of the articulation editor will allow the articulationID to be passed to the MIDI scripter. Mystery solved for now.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...