Duplex Beta Versions


(danoise) #321

Cool, I will of course help in any I can - seems like you’re already on the right track.

Duplex has a built-in MIDI dump feature that you can enable. Perhaps you could try to turn a few of those encoders and see if anything is displayed in the console?
You can post that info here and we can look into it.

The drum pads are configured to respond to notes C-4 through G-4 (check out the control-map here), perhaps you assigned some different notes?
Whatever is the reason, the controlmap should reflect the notes that were specified in the automap editor.
EDIT: just make sure that the the note is offset by one octave - C3 in automap translates to C4 in Renoise.

Of course it would be possible to adapt the StepSequencer to this format as well, but currently, you might want to check out N.O.W. for a dial-based sequencer?

The reason is that it gives us access to the topmost buttons on the Launchpad. But automap is needed on the Remote because bi-directional communication on the Remote doesn’t work without it.
PS: you are using Automap 4.4? If not, it’s recommended to upgrade to this version, as Novation have fixed an issue that has been causing problems since 3.7


(Niall) #322

Hi Danoise,

Thanks for your reply.

I will try and give you the information as clear as I can.

Well on the first encoder, I just get this when I rotate:

MidiDevice: Automap MIDI received MIDI B0 0 3F  
MidiDevice: Automap MIDI received MIDI B0 0 3F  
MidiDevice: Automap MIDI received MIDI B0 0 3F  
MidiDevice: Automap MIDI received MIDI B0 0 3F  
MidiDevice: Automap MIDI received MIDI B0 0 3F  

I think it’s just repeating whatever the value is, and not changing it.

I get nothing with the 2nd (cc#1), and 3rd (cc#2) knobs.

With the 4th (cc#3) knob, I get this repeated.

MidiDevice: Automap MIDI received MIDI B0 3 3F  
MidiDevice: Automap MIDI received MIDI B0 3 3F  
MidiDevice: Automap MIDI received MIDI B0 3 3F  

and the same with the 5th (cc#4)

MidiDevice: Automap MIDI received MIDI B0 4 59  
MidiDevice: Automap MIDI received MIDI B0 4 59  
MidiDevice: Automap MIDI received MIDI B0 4 59  

then nothing from knobs 6,7, and 8.

Cycling through the drum pads brings up this.

MidiDevice: Automap MIDI received MIDI 90 48 0  
MidiDevice: Automap MIDI received MIDI 90 48 0  
MidiDevice: Automap MIDI received MIDI 90 49 36  
MidiDevice: Automap MIDI received MIDI 90 49 36  
MidiDevice: Automap MIDI received MIDI 90 49 36  
MidiDevice: Automap MIDI received MIDI 90 49 0  
MidiDevice: Automap MIDI received MIDI 90 49 0  
MidiDevice: Automap MIDI received MIDI 90 49 0  
MidiDevice: Automap MIDI received MIDI 90 4A 57  
MidiDevice: Automap MIDI received MIDI 90 4A 57  
MidiDevice: Automap MIDI received MIDI 90 4A 57  
MidiDevice: Automap MIDI received MIDI 90 4A 0  
MidiDevice: Automap MIDI received MIDI 90 4A 0  
MidiDevice: Automap MIDI received MIDI 90 4A 0  
MidiDevice: Automap MIDI received MIDI 90 4B 7F  
MidiDevice: Automap MIDI received MIDI 90 4B 7F  
MidiDevice: Automap MIDI received MIDI 90 4B 7F  
MidiDevice: Automap MIDI received MIDI 90 4B 0  
MidiDevice: Automap MIDI received MIDI 90 4B 0  
MidiDevice: Automap MIDI received MIDI 90 4B 0  
MidiDevice: Automap MIDI received MIDI 90 4C 4B  
MidiDevice: Automap MIDI received MIDI 90 4C 4B  
MidiDevice: Automap MIDI received MIDI 90 4C 4B  
MidiDevice: Automap MIDI received MIDI 90 4C 0  
MidiDevice: Automap MIDI received MIDI 90 4C 0  
MidiDevice: Automap MIDI received MIDI 90 4C 0  
MidiDevice: Automap MIDI received MIDI 90 4D 7F  
MidiDevice: Automap MIDI received MIDI 90 4D 7F  
MidiDevice: Automap MIDI received MIDI 90 4D 7F  
MidiDevice: Automap MIDI received MIDI 90 4D 0  
MidiDevice: Automap MIDI received MIDI 90 4D 0  
MidiDevice: Automap MIDI received MIDI 90 4D 0  
MidiDevice: Automap MIDI received MIDI 90 4E 7F  
MidiDevice: Automap MIDI received MIDI 90 4E 7F  
MidiDevice: Automap MIDI received MIDI 90 4E 7F  
MidiDevice: Automap MIDI received MIDI 90 4E 0  
MidiDevice: Automap MIDI received MIDI 90 4E 0  
MidiDevice: Automap MIDI received MIDI 90 4E 0  
MidiDevice: Automap MIDI received MIDI 90 4F 7F  
MidiDevice: Automap MIDI received MIDI 90 4F 7F  
MidiDevice: Automap MIDI received MIDI 90 4F 7F  
MidiDevice: Automap MIDI received MIDI 90 4F 0  
MidiDevice: Automap MIDI received MIDI 90 4F 0  
MidiDevice: Automap MIDI received MIDI 90 4F 0  
  

All encoders work fine when not using automap, so I’m not convinced this is a duplex problem, and not an automap one.
But the problem is that I have so few controls in automap, that I’ve pretty much changed all I can.

Also yep, my automap and controller are up to date.

To be honest, I haven’t properly played with the N.O.W as I needed to get everything working first, so it may be what I’m looking for.
Otherwise, it will be a spot of playing with the step sequencer.

In which case, would I need to edit the Duplex step sequencer app?
Or should I be able to do everything just with my own control maps and templates?

Thanks a lot either way,


(danoise) #323

Yup, that’s what it looks like. Are you sure you didn’t assign some invalid range in the automap editor? A “normal” assignment going from 0-127 should be the default.
Those knobs will never be usable before they have a range of some kind.

Well, even weirder.

That looks fine to me. Note that C3 in automap editor corresponds to C4 in Renoise and in the Duplex controlmap.
To actually trigger notes, Duplex is using the Keyboard application (it’s called Drumpads in the packaged Remote configuration), and has some benefits over standard MIDI notes - most importantly, the Remote drumpads are sending multiple note-on, but only a single note-off when you are using them. The Keyboard application works around this, so you don’t get any stuck notes.

As for the step-sequencer, yes it needs to be modified quite a bit in order to support knobs. Right now, N.O.W (Notes on Wheels, the wheels being your knobs :wink: ) is more suitable, and IMO a lot more expressive and fun.
Try looking at the “Custombuilt” entries in the Duplex tool menu to check out the full-blown and compact example configurations.


(Niall) #324

Of course, it would be a automap error.
http://www.novationmusic.com/answerbase/en/article.php?id=722
Why google didn’t show me this the first few times I searched for it I don’t know. Anyway, the rotary encoders work now!
As do the drum pads, which needed to be set to C-3 in automap rather than C-4 as you said.

All in all looks like it’s working well, and a whole lot of fun.

I’ll check out notes on wheels, and if I can clean up my template enough I’ll put it up here in case someone else wants it.

Thanks a lot Danoise.


(danoise) #325

A new version is ready - download it here

It contains a new application called MidiActions that will expose standard Renoise mappings as fully bi-directional mappings,
customizable scaling (exponential, logarithmic, linear) and range.

It literally provides access to hundreds of features inside Renoise, such as BPM, LPB, and even UI view presets. You will have
to map each feature manually, but once mapped it’s fire-and-forget. Check out the demonstration in “Tools/Duplex /Custombuilt”,
and try to ignore the obscene amount of work put into that one, you most likely want to map just a few controls :badteeth:

Full changelog:

 
MidiActions  
* New application: MidiActions.lua (designed to piggy-back on GlobalMidiActions)  
 
Duplex Core  
* Feature: optional MIDI quantize (MIDI controllers, when using UISlider)  
* Applications now receive __init arguments via vararg (easier to expand)  
* Application mappings, palette now defined as static tables  
* Device config: allow “literal” option values (supply string value)  
* Application options: sort entries alphabetically  
* Application options: “break” into columns for every xx entries  
 
Grid Pie  
* FIXME (Recording) better handling of patt. cloning near boundaries  
* TWEAK “Keep the beat” changed to modify playback-pos less often  
* FIXME Sess-rec.: “Stuttering” after short pattern (incremental_update)  
* FIXME Assign to slot: use patt-idx, not seq-idx (doh!)  
* FIXME Do not block “trigger gestures” in separate tracks  
* FEATURE Record: when triggering a pattern, use incremental updates  
* FEATURE Shorten pattern instead of modifying playback-pos (when possible)  
* FEATURE skip group tracks when temp-muting  
* FEATURE When muting track, delay note-off (to keep existing instr.)  
* FIXME Incremental updates should use the master slot range only  
* FIXME Don’t signal “dun goofed” when not started  
* USABILITY Restore matrix state when GP pattern is “dun goofed”  
 
Device-configs  
* Remote-SL-MKII/MixerEffectsTransport: swapped Mixer(mutes) with TrackSelector  
* Custombuilt MidiActions_Demo (demonstrates an 8-track mixer and transport)  
* Remote SLMKII MidiActionsTest (demo of button-slider and fixed BPM buttons)  
* Launchpad MuteGrid (as an example of "control-map hacking")  
 
 

(artfwo) #326

The new beta fails to install with the following message here, is anything wrong at my side or just something is missing from the bundle?

'/home/art/.renoise/V2.8.1/Scripts/Tools/com.renoise.Duplex.xrnx/' failed to load.  
  
Please remove this tool or contact the author (danoise [bjorn.nesby@googlemail.com]) for assistance...  
  
./Duplex/Applications/MidiActions.lua:78: module 'Scripts/GlobalMidiActions' not found:  
 no field package.preload['Scripts/GlobalMidiActions']  
 no file './Scripts/GlobalMidiActions.lua'  
 no file '/usr/local/share/lua/5.1/Scripts/GlobalMidiActions.lua'  
 no file '/usr/local/share/lua/5.1/Scripts/GlobalMidiActions/init.lua'  
 no file '/usr/local/lib/lua/5.1/Scripts/GlobalMidiActions.lua'  
 no file '/usr/local/lib/lua/5.1/Scripts/GlobalMidiActions/init.lua'  
 no file '/home/art/.renoise/V2.8.1/Scripts/Libraries/Scripts/GlobalMidiActions.lua'  
 no file '/home/art/opt/rns_2_8_1_reg_x86_64/Resources/Scripts/Libraries/Scripts/GlobalMidiActions.lua'  
 no file './Scripts/GlobalMidiActions.so'  
 no file '/usr/local/lib/lua/5.1/Scripts/GlobalMidiActions.so'  
 no file '/usr/local/lib/lua/5.1/loadall.so'  
 no file '/home/art/.renoise/V2.8.1/Scripts/Libraries/Scripts/GlobalMidiActions.so'  
 no file '/home/art/opt/rns_2_8_1_reg_x86_64/Resources/Scripts/Libraries/Scripts/GlobalMidiActions.so'  
stack traceback:  
 [C]: in function 'require'  
 ./Duplex/Applications/MidiActions.lua:78: in main chunk  
 [C]: in function 'require'  
 ./Duplex.lua:36: in main chunk  
 [C]: in function 'require'  
 main.lua:7: in main chunk  

(danoise) #327

Opps, thanks for that.

MidiActions is trying to locate the file called GlobalMidiActions.lua on startup, so it can pick it apart.
Obviously, something went wrong during that process.

What is your operating system?

PS: As a workaround, you could copy the file into one of the locations you see in that error message, and it should be able to continue


(artfwo) #328

Linux x86_64.

Copying the file from my Renoise install dir to ~/.renoise/V2.8.1/Scripts/Libraries/Scripts/GlobalMidiActions.lua works. Confounding, because the file is located under rns_2_8_1_reg_x86_64/Resources/Scripts, it’s just not being found by the tool loader.


(Niall) #329

Got the same error on osX.

  
./Duplex/Applications/MidiActions.lua:78: module 'Scripts/GlobalMidiActions' not found:  
 no field package.preload['Scripts/GlobalMidiActions']  
 no file './Scripts/GlobalMidiActions.lua'  
 no file '/usr/local/share/lua/5.1/Scripts/GlobalMidiActions.lua'  
 no file '/usr/local/share/lua/5.1/Scripts/GlobalMidiActions/init.lua'  
 no file '/usr/local/lib/lua/5.1/Scripts/GlobalMidiActions.lua'  
 no file '/usr/local/lib/lua/5.1/Scripts/GlobalMidiActions/init.lua'  
 no file '/Users/Niall/Library/Preferences/Renoise/V2.8.0/Scripts/Libraries/Scripts/GlobalMidiActions.lua'  
 no file '/Applications/Renoise 2.8/Renoise_Reg_Intel32.app/Contents/Resources/Scripts/Libraries/Scripts/GlobalMidiActions.lua'  
 no file './Scripts/GlobalMidiActions.so'  
 no file '/usr/local/lib/lua/5.1/Scripts/GlobalMidiActions.so'  
 no file '/usr/local/lib/lua/5.1/loadall.so'  
 no file '/Users/Niall/Library/Preferences/Renoise/V2.8.0/Scripts/Libraries/Scripts/GlobalMidiActions.so'  
 no file '/Applications/Renoise 2.8/Renoise_Reg_Intel32.app/Contents/Resources/Scripts/Libraries/Scripts/GlobalMidiActions.so'  
 no file '/Users/Niall/Library/Preferences/Renoise/V2.8.0/Scripts/Libraries/Scripts/GlobalMidiActions.dylib'  
 no file '/Applications/Renoise 2.8/Renoise_Reg_Intel32.app/Contents/Resources/Scripts/Libraries/Scripts/GlobalMidiActions.dylib'  
stack traceback:  
 [C]: in function 'require'  
 ./Duplex/Applications/MidiActions.lua:78: in main chunk  
 [C]: in function 'require'  
 ./Duplex.lua:36: in main chunk  
 [C]: in function 'require'  
 main.lua:7: in main chunk  

(danoise) #330

It seems that on Linux and OSX, GlobalMidiActions isn’t accessible until you take a copy and put in the user-pref “Scripts” folder.
This is the reason I didn’t discover the error, I did have some modifications of my own while testing with OSX. Oh well…

In the application, I first check for the presence of a user-modified version, and
perform some tricks on the lua package path variable:
local old_package_path = package.path
package.path = package.path … “;./…/…/?.lua”
require “GlobalMidiActions”
package.path = old_package_path

This part works, but it’s only called when the file exists.
Problem is, if it doesn’t, a simple statement like this doesn’t work:

require “Scripts/GlobalMidiActions”

Perhaps some sort of OS-specific workaround could be implemented here?

EDIT: Expanding on that, if I print the “package.path” on my OSX (Snow Leopard) I get the following:

./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua;/Users/nesby/Library/Preferences/Renoise/V2.8.1/Scripts/Libraries/?.lua;/Applications/Renoise_2.8.1_Intel64.app/Contents/Resources/Scripts/Libraries/?.lua

Basically, I could extract the path from the statement that begin with “/Applications/” and then shorten it to look inside “/Scripts”
But I’m not sure how well that would translate to other systems, this would need a bit more research, trial and error style.


(artfwo) #331

So basically the load path should include %prefix%/Resources/Scripts/?.lua in addition to %prefix%/Resources/Scripts/Libraries/?.lua, right?

(where %prefix% is both the installation path and user preferences version-specific directory).


(danoise) #332

@artfwo: yes, but we’d need to perform an io.exists() check before actually including the file, or it will throw an error.
But io.exists() does not rely on package paths, so we need to obtain the exact paths in order to be sure.

I have come up with the following approach - it works on my OSX machine (Snow Leopard), and hopefully also Linux?
To install, just replace MidiActions.lua with the new version and reload the tools
EDIT: Original download location and SVN has been updated

  
  
 -- Linux, OSX: look for locations by parsing "package.path"   
  
 local default_location = nil  
 local user_provided = nil  
 local iterator = string.gmatch(package.path,";([^;]+)")  
  
 for str in iterator do  
 if (string.sub(str,-24)=="/Scripts/Libraries/?.lua") then  
 if string.find(str,"Resources") then  
 user_provided = str  
 else  
 default_location = str   
 end  
 end  
 end  
  
 local make_path = function(str_path)  
 local str_result = str_path:gsub("/Libraries","")  
 return str_result  
 end  
  
 local literal_path = function(str_path)  
 local str_result = str_path:gsub("?","GlobalMidiActions")  
 return str_result  
 end  
  
 default_location = make_path(default_location)  
 user_provided = make_path(user_provided)  
  
 local path_addendum = nil  
 if io.exists(literal_path(user_provided)) then  
 path_addendum = user_provided  
 elseif io.exists(literal_path(default_location)) then  
 path_addendum = default_location  
 end  
  
 if path_addendum then  
 local old_package_path = package.path  
 package.path = package.path .. ";" .. path_addendum  
 require "GlobalMidiActions"  
 package.path = old_package_path  
 actions_loaded = true   
 end  
  

(artfwo) #333

Yay, not it works! ^_^ Thanks for the fix!


(danoise) #334

Cool. I’m still crossing my fingers that this approach is solid enough, but I guess that’s what a beta version is for :lol:

I’ve updated the download link and SVN on google code. From now on, it’s strictly about fixing any remaining bugs before we move on.


(Bernhard) #335

Hey guys,

this is my first post on this forum so i say Hello everbody!

I get this message when i try to install:

  
./Duplex/Applications/MidiActions_bindings.lua:42: variable 'MidiActions' is not declared  
stack traceback:  
 [C]: in function '_error'  
 [string "local mt = getmetatable(_G)..."]:29: in function   
 ./Duplex/Applications/MidiActions_bindings.lua:42: in main chunk  
 [C]: in function 'require'  
 ./Duplex.lua:36: in main chunk  
 [C]: in function 'require'  
 main.lua:7: in main chunk  
  

This is on Fedora Linux with Renoise 2.8.1

I hope this is useful.


(danoise) #336

Hi, and welcome :slight_smile:

that MidiActions application is sure causing a lot of trouble -
I think it has to do with the loading order of things: the application should be loaded before the “bindings”, but in your case it seems not to.
I’ll need to come up with a fix for this, obviously…

In the meantime you can simply remove the application by locating the applications folder in Duplex
(open the tools browser, right-click Duplex to reveal it’s location). Then go to the “Applications” and delete the two files that start with MidiActions)


(Bernhard) #337

Thanks!

It works. it seems i have to look into the mpd24 preset.
some knobs don´t work. :(
if i can make it work properly i let you know and send you the preset
if that is the problem here.
i just used renoise one day now. still a lot to learn…


(danoise) #338

I’ve looked into the issue, the next version will do things a little differently.

As for the MPD24, try enabling “dump MIDI to console” in order to see what messages are received by Renoise, might be useful…


(danoise) #339

A new version has arrived. Some bug fixes, some new features.
As usual, the topic has been updated with the download link. Also on SVN

The big news is the Repeater application. It’s simple enough to use, but I’ll post some more info -
until then you can check out the Launchpad, Remote or monome configs :slight_smile:

  
* New application: Repeater.lua  
* New UIComponent demo: Custombuilt/UISlider_Demo  
* New Remote-SL-MKII configurations: MidiActions, Repeater and XYPad  
* Fixed: Effect.lua: special check for negative value (MTDelay "panic" will fire -1)  
* Fixed: Display.lua: XYpad values are updated with an untranslated value  
* Fixed: XYPad.lua: invalid ceiling value  
* Application: Keyboard.lua - support for distributed parameters (key_grid)  
* Application: MidiActions.lua - moved the bindings file to a sub-folder, so we  
can control the loading order. Also, support no-orientation  
* Application: Mixer.lua - support for distributed parameters (levels, mute, panning)  
* Config: KONTROL-49/Keypads.lua - removed superfluous index for greedy assignment  
* Config: KONTROL-49/Mixer.lua - added "follow_track" as default option  
* Config: Launchpad/MuteGrid.lua - some additional tweaks for Bryan  
* Config: Monome128 + Launchpad/XYPad.lua - now contains the Repeater application (new name: XYPad + Repeater)  
* Config: Ohm64/[all configurations] - using the new wildcard assignment to run a single Mixer instance   
* Config: Remote SL MKII/MidiActionsTest (deleted)  
* Config: Remote SL MKII/[all configs] - added "follow_track" as default option for Mixer  
* Core: ControlMap - new method, get_param() - will allow a mapping to use wildcard syntax.  
* Core: Automation.lua - provide "playmode" (env. interpolation) as argument to add_point()  
* Core: UISlider.lua - the slider can now work in "no-orientation" mode (see CustomBuilt -> UISlider Demo)  
* Core: MessageStream.lua - finetuned the "pass-on" method (and updated all UIComponents)  
* Core: MidiDevice.lua - removed value-casting from point_to_value() (no longer needed, as this is done when XML is parsed)  
* Core: UISlider/UIButton/UIKey/UIPad/UISpinner.lua - changes to reflect the refined "pass-on" method  
* Core: UISpinner.lua - now has "dummy" release method (again, because of the "pass-on" method)  
  

(danoise) #340

Another update arrived yesterday, download link is provided in the first post
It contains (pending) support for the QuNeo controller, and support for relative encoders (7bit MIDI devices only).
I’ve tested the relative encoders with my own Nocturn and Remote units, but others may benefit from it as well

Also, I refactored some classes in order to make it easier to write a dedicated application for controlling
a particular DSP device. The new class is called “RoamingDSP”, which is now employed by these
three applications: the XYPad, Repeater and Hydra

Finally, there has (again) been some modifications to how the MidiAction application is initialized,
it might be able to run on certain installations where it previously failed.

  
* Added new device: QuNeo  
* New core class: RoamingDSP, for writing effect applications  
* New application: Hydra, demonstrates how to use the RoamingDSP class  
* Also adapted to RoamingDSP: Repeater.lua, XYPad.lua  
* Display.lua - include parameter as argument for virtually generated events  
* Display.lua - include elm,point as argument when sending notes (QuNeo support)  
* Globals.lua - dedicated LOG method for printing stuff to the console  
* MidiDevice.lua - make use of LOG method where appropriate  
* UISlider.lua - relative encoder support (7-bit). See http://goo.gl/tqurD  
* New device-config: Nocturn Hydra