AddRoutes

Introduction

MIDI/OSC and More (M.O.M) has been renamed as AddRoutes in March 2020 ! 

AddRoutes is a new Add-on for Blender 2.8 gathering AddMIDI and AddOSC in the same package. As a novelty an application for smartphones and tablets (Blemote) is currently developed to ease the remote control of Blender.

In this section, we deal with installation and general configuration, see the other pages for further informations in the right menu.

Download

For the last release "ready to go" (Windows, OSX, and Linux), here is the LINK. We are now targeting Blender 2.93 LTS which runs with Python 3.9.

If you still want to use prior versions of Blender (for instance Blender 2.83 LTS or Blender 2.92) based on Python 3.7 use this link to get AddRoutes v0.32 (which will be the last supported version for them).  

Disclaimer: By downloading this software you understand that AddRoutes is still under development and that some problems might occur during its use.

For installation, like any Add-ons, don't unzip and do "Install From file", then look in the category "System" to enable it.

Important: If you upgrade from M.O.M, make sure you uninstall it before installing AddRoutes. Don't worry if you have some errors while disabling M.O.M. Save the preferences, restart Blender, then install and enable AddRoutes.

The Add-on is now located in the "N panel", at the right, and has 2 tabs (AddR Config and Routes).

License and Status

AddRoutes inherits from the Blender license which is the GNU GPL license (like all Blender Add-ons). 

Development and maintenance of this Add-on has been a lot of work. If you can, please support financially this project.

Even though the Add-on can already be useful, it needs some polishing and new handy features and improvements can be wished. Please share your thoughts. 

A thread on BlenderArtists can be found here.  

If you are a developper sources can be found on github: https://github.com/JPfeP/AddRoutes.

Add-on Settings

In the Blender Preferences Panel search for AddRoutes, and unfold its section.

General settings

  • Refresh rate of engine (ms): The default value (1ms) might be unecessary low as it will be usefull only for 1000 FPS animation. 
  • Maximum events per cycle: As well adjust to your taste. If the limit is reached, the stack is cleaned and the overrun counter incremented (displayed in the Tools Panel).  

Debug settings

  • Copy all in/out debug messages in the text editor: By default the debug messages appear in the console of your computer. But this requires to launch Blender from the terminal. With this option, theses messages will be copied in a text file that you can see updated in realtime with each new event. A new text file called  'AddRoutes: Debug in/out' will be automatically created if necessary.

  • Add time stamp to debug messages: add the local time of your computer to each debug message. 

Blemote Settings

The Blemote options are explained in the Blemote page.

There is now a new debug option as well which is stored in the preferences (contrary to the others engine).

MIDI System Settings

It's now possible to configure default settings for MIDI. These settings are exposed both in this panel and in the "N" Config tab for AddRoutes for convenience. 

These options are detailed in the MIDI page.   

OSC System Settings

It's now possible to configure default settings for OSC. These settings are exposed both in this panel and in the "N" Config tab for AddRoutes for convenience.

These options are detailed in the OSC page.    


About Recording

Please be cautious with the "rec" button. It relies on the "is_playing" flag that Blender turns "on" and "off" when you play the current animation OR when you move the playhead manually. 

You might be better off to disable "rec" on a route just after the recording to avoid unwanted keyframe insertions while you move the playhead inadvertently.

You don't need to enable the auto-keying button in the Timeline, it's a different feature.  

Sending

This feature is active only when Blender is playing. This is mostly to prevent unneeded CPU usage during editing. The Add-on compare at each new frame if the chosen properties in your routes have changed. If yes their values are sent. If not there is no sending. If a given route has some extra calculation (like MIDI rescaling), the change is evaluated on the post-treatment value. So a blender property can change but not its result after the Add-on's evaluation, so no sending will happen in this case.  

 

Workflow

It's a very personal subject, but if I could share a few hints, I would advise to work at first as much as possible in realtime without using much keyframing. The "revolutionary" aspect of this add-on is to be able to work both on music and 3D visuals at the same time, under some very good conditions. EEVEE is a blessing and a strong opportunity for a new kind of creators who would want to push the art of videoclips way beyond its current state. Computers are fast, storage and RAM are cheap, it's time to invest in some new hardware and be amongst the firsts to seize this opportunity. 

These new conditions will still imply nonetheless to have a reflection about means in art. EEVEE can require a quite powerful GPU that not everybody have. You might still have to prevent yourself from using too heavy objects or too crowded scenes to keep the frame rate steady. Art is about emotion not technicity, and time is the matter.  

After theses pure realtime experimentations may be a definitive art work project is starting to emerge. And after good planification you might want to produce a first final video. At this point, things might get less clear, as several strategies could lead to the final product equally well. 

To get very predictable results, and tight sync'ing, it's obvious that recording or converting the incoming data flux helps. Each engine offers a few methods. One is simply recording in Blender the realtime events, another is converting them when they can be made available as saved file (a midifile or to a textfile in the case of OSC with software like Puredata for instance).

For MIDI data, converting notes to keyframes could be however probably avoidable in many simple cases. But your mileage may vary, and it would be still mandatory if you want to apply post treatment on the shapes of the F-curves. Another limit could be you need more than 16 tracks. I would then advise to convert only monophonic channels or to break the project into several midifiles. 

On this subject, it might be a good idea, specially with a project that lasts more than a simple video clip to break each part into several midifiles and may be into several D.A.W. files as well. Blender would render each sequence as frames that in turn you would gather into a final video project (either using the Blender VSE or another application) 

Things to know

  • Don't use "location.x" or "location[0]" when you set a data-path manually but "location", then set the index that will appear. Same for any property being an array (like colors). 
  • Frame dropping as sync method might produce incoherent results while making a midifile contribute during playing
  • Using a animation step > 1 is not supported for midifile contributing, but shouldn't be a pbm for converting. 
  • MIDI CC's 98 and 100 are reserved for RPN/NRPN and cannot be used currently (might change later) as simple 7bit continuous controllers. 
  • Angles are expressed in radian internally thru the Python API by Blender (and therefore the add-on complies), and not in degree like in the interface. 360° = 2*pi. The Add-on however offers an option for conversion (done in python).
  • Using drivers is fast (no python calculation) and offers nice added features. Instead of targeting directly an object property, you can create an empty object and use its axis location X, Y, Z as the support for the information you want to inject in Blender. Then, with a driver you can control even more the information and shape it with curve to control the object you really want to animate.
  • Custom properties are not directly supported at this point. But using drivers to target them is, again, a solution.  
  • You can enable both "Tooltips" and "Python Tooltips" in Preferences/Interface/Display to have information about the path of a property when the mouse hover on it. This helps a lot to solve some problems while setting routes manually.
  • Blender sometimes uses "bridges" internally to describe the path of a property (called as nested properties in the documentation). For clarity, you might want to select the proper category "Key" (for shapekeys) instead of using "Object" then have a bridge (like "data") in the path. For instance, these 2 properties are the same: bpy.data.objects['head'].data.shape_keys.key_blocks['eyeBlink_L'].value  bpy.data.shape_keys['Key'].key_blocks['eyeBlink_L'].value
  • Another oddity is that historically the Node System was only for material shaders then it was generalized to be used for many usages. However, Blender keeps a special treatment for material shaders, when you enable the nodal system, you won't find your material available in the Nodes category. Therefore the add-on has special code to handle this frequent exception.      

Credits

This Add-on relies on a few libraries:

JPfeP