Duplex Beta Versions

Try setting the matrix to scroll in increments of 4 instead of “automatic” - in Duplex settings → Matrix → page size. Then, you’re scrolling sideways in the matrix with a step-size of 4 and up/down with a step size of 8.

Another feature in this release is serialosc <-> monome interoperability

Both monomeserial and serialosc are pieces of software which sit between a monome device and the software using it. On the surface, however, the difference between the two is small - it basically boils down to how the control-map values are written.

But while this is a small difference, it would be tedious to maintain a growing number of control-maps in two different versions. Instead, Duplex is now translating the newer control-map format into the older one on-the-fly, to avoid breaking existing setup. However, it is recommended that you update to serialosc if possible. Not only because it’s newer, but also because Duplex wouldn’t have to translate anything then, possibly saving a few CPU cycles in the process.

After you have installed serialosc and confirmed it’s working, the switch is simple to perform:

First, open your monome device folder and locate the file named “monome.lua”. Inside the file, locate this line:

self.comm_protocol = self.MONOMESERIAL  

and change it to

self.comm_protocol = self.SERIALOSC  

I don’t think you need to support monomeserial at all.

http://docs.monome.org/doku.php?id=setup

Ah, but so far Duplex has used monomeserial without a problem, and although it might not be supported forever, there are reasons for it’s continued support:

The primary reason is not to break anyone’s existing setup. Convenience, you might say. The second reason is that I never could get serialosc to work on my windows machine. Believe me, I tried. Monomeserial, on the other hand, is working fine there.
And then there’s still plenty of monome scripts around which have never been updated. But since you can’t have monomeserial and serialosc running at the same time, the interoperability feature is quite valuable in such a situation.

Mad props.

Combo reply to this and this.

Testing from SVN.

http://www.youtube.com/watch?v=mHKVuTwFNyU

Download AKAI LPD8 Editor: http://www.akaipro.com/lpd8

Video tutorial on how this editor thing works, it’s flaky so keep trying: Click here.

Load and commit the preset file in:

  
OSX: /Users/<username>/Library/Preferences/Renoise/<version>/Scripts/Tools/com.renoise.Duplex.xrnx/Duplex/Controllers/AkaiLPD8/Presets/<br>
<br>```

<br>
<br>
Make sure MIDI input is disabled in Renoise preferences. <br>
<br>
Launch Duplex, select your LPD8 in the Duplex settings.<br>
<br>
Select CC Mode (not Pad)<br>
<br>
Cut &amp; Pastry!<br>
<br>
PS: Got some sort of crash?<br>
<br>

[details="Click to view contents"]

```<br><br>
ScriptingEngine: ./Duplex/Browser.lua:1462: attempt to call method 'settings_dialog_visible' (a nil value)<br>
stack traceback:<br>
	./Duplex/Browser.lua:1462: in function <.><br>
<br>
ScriptingEngine: ./Duplex/Browser.lua:1462: attempt to call method 'settings_dialog_visible' (a nil value)<br>
stack traceback:<br>
	./Duplex/Browser.lua:1462: in function <.><br>
<br>
ScriptingEngine: ./Duplex/Browser.lua:1462: attempt to call method 'settings_dialog_visible' (a nil value)<br>
stack traceback:<br>
	./Duplex/Browser.lua:1462: in function <.><br>
<br>
ScriptingEngine: ./Duplex/Browser.lua:1462: attempt to call method 'settings_dialog_visible' (a nil value)<br>
stack traceback:<br>
	./Duplex/Browser.lua:1462: in function <.><br>
<br>
ScriptingEngine: ./Duplex/Browser.lua:1462: attempt to call method 'settings_dialog_visible' (a nil value)<br>
stack traceback:<br>
	./Duplex/Browser.lua:1462: in function <.><br>
<br>```

[/details]

</.></.></.></.></.></version></username>

3 x Poly Combo

Great that you actually recorded that video, and let me just see what I gather from it…

  1. It really is a damn shame that the editor is needed. Plug’n’play…pfff

  2. The flashing is because certain types of buttons needs to be set back to their correct state. But once we find the right type (based on what the MIDI dump data might say), the flashing may or may not appear.

  3. The knob that appeared in the wrong place, my bad. I’ve attached a corrected control-map.

I’ve not been able to reproduce this, but I see that you like to close the Duplex browser - note that this does not stop any running applications (you can have several controllers running at the same time).
Do you have any idea about what you did when this happened - i.e., was the dialog closed?

Here are some further refinements that I think Grid Pie could benefit from:

Question: should the “restore matrix state” happen when playback is stopped, or should we instead hook it up to the actually running state of the application (the “Run” checkbox)?
To me, it would seem sort of logical to have an option which control the playback state like this:

Option: Playback sync

  1. Enabled - auto-start playback when application is launched, restore matrix state when playback is stopped
  2. Disabled - playback is controlled manually, matrix state is restored once application is stopped

(1) would also accommodate D.A.T.'s wish, to be able to switch between applications, while (2) would be the one I’d prefer.

Similarly, I’d like to expand on the “follow_pos” option like this:

Option: Matrix navigation

  1. Set position - the original Grid Pie mode, will select the current track/pattern as tracks are being copied*
  2. Set and follow - the original mode + it will track the currently selected track/pattern in Renoise*
  3. Do nothing - will initially set the position to the GRID PIE pattern, but otherwise leave the position unaltered
  • In this mode, enabling follow_playback is actively prevented.

On second thought, ditch the first option. Make it just

Matrix navigation: “Follow” or “Do nothing”…

Duplex 0.98b7 has arrived (wow, did I really say that b4 was probably the last one for now )

Anyway, the big news this time is…

2614 duplex_menu.png

The Duplex menu has been overhauled, with each device now located in it’s own sub-folder.
The reason is that - even on large screens - the number of devices and configurations couldn’t fit anymore. Well, now they should be able to.

  • New entry in tool menu: “Release all open devices” - basically just a shortcut, but it might not have been too obvious before.
  • New entry in tool menu: “Display on startup” - will make the browser appear automatically (but only when a configuration is launched on startup).
    This is also great news for those of us who like to dabble with control-maps and/or applications, as all we need to do now is to select “Reload all tools”

Grid Pie (the Duplex port) has also received numerous bug fixes and improvements

  • The navigation scheme now supports other Duplex apps. This means that you can align e.g. the Mixer with Grid Pie (see the Launchpad configuration for an example).
  • More responsive than ever (but further optimizations are planned) + optional auto-start when application is launched
  • Plug-and-play for the following devices: LPD8, monome128/64, Launchpad, KONTROL49, with more planned (think your controller can run Grid Pie? Let us know)

See first post for download and more info…

Waaah! finally!! :guitar:

@DoubleDeep: about the Mute button’s behavior of nanoKONTROL2. (I hope you still see here)

Finally I found the cause of this issue. I guess that the cause is the Win Vista/7 native midi driver.
If you install KORG USB-MIDI Driver
and set [Mixer] >> [Invert display] >> [Button is lit when track is muted] on the Duplex’s option panel, it should work as you expect. (I’ve confirmed it on my system :) )

:excl: [note]
If you install KORG USB-MIDI Driver, the midi port names will be changed like below. So you should reselect each in/out port on each nanoK2’s config of Duplex.

According to the nanoK2’s manual:
[OS] : [MIDI IN] : [MIDI OUT]

  • [Mac OSX] : [nanoKONTROL2 SLIDER/KNOB] : [nanoKONTROL2 CTRL]
  • [Win Vista/7] : [nanoKONTROL2] : [nanoKONTROL2]
  • [Win XP] : [USB audio device] : [USB audio device]
  • [Win XP/Vista/7 + KORG USB-MIDI Driver] : [nanoKONTROL2 1 SLIDER/KNOB] : [nanoKONTROL2 1 CTRL]

Hey sato - I’m guessing you’ve tried switching drivers to eliminate the nanoKONTROL2 freezing issue.
Did it work, or is it still causing periodic freezing in Renoise/Ableton/etc. ?

Anyway, the inverted mute display was fixed by me. No need to update drivers, just to make this work. Sorry for not mentioning this
As I stated earlier, the inverted display was merely thought of a convenience thing for the Launchpad. But also kind of a ugly hack, really.
With this recent update, I simply took the time to make it into a proper solution which should work across devices (the option is still hidden from Duplex preferences though).

Btw Sato: now that we have restructured device folders and menu, maybe Duplex should act a bit smarter and simply include files ending with “.lua” that reside in “SomeDevice/Configurations”? Having to manually include config-files from the device file sort of seem like an unnecessary step …

Unfortunately, periodic freezing still remains especially when I use Duplex.
About this, please see Alpha forum too.

Haha, sorry for my misunderstanding. Now I confirmed it works even without KORG’s driver. :P

Ahh sorry, I cannot understand about this sentence (a bit difficult for me). What do you mean?? :huh:

I’ll just re-phrase: we now have a different folder structure for devices. It’s simpler to open and modify some configuration, because all you need is to open the file, and you no longer have to scroll down to get to the actual configuration part. This is easier to work with, not just for non-programmers, but for everybody.

Now, what I’m suggesting is, that just like Duplex automatically look for devices, it should also include device configurations. Because currently, when you add a configuration, you also need to add it to the list of configurations (which is manually specified in the SomeDevice.lua file). I basically want to get rid of that extra step, and simply include all lua files that reside in “SomeDevice/Configurations”.

Whaddaya Think?

Ahh, simply copy the code in the nanoKONTROL2.lua(for example) to every configuration lua file, and delete the nanoKONTROL2.lua file??
I’m OK to do so, no problem at all. :)

No, it’s much simpler. I’m basically saying: to add a new device config, simply put the device configuration into /Configurations - and it will be included the next time Duplex is launched.
Also, this means that we can remove stupid and unnecessary sections like this one from nanoKONTROL2.lua:

– Include these configurations

local CTRL_PATH = “Duplex/Controllers/nanoKONTROL2/Configurations/”
require (CTRL_PATH…“MixerTransport”)
require (CTRL_PATH…“RecorderTransport”)
require (CTRL_PATH…“StepSequencerTransport”)
require (CTRL_PATH…“NotesOnWheels”)

I hope I made myself clear this time? I just wanted your opinion & input

Yes, I can understand now. Go go!! :D

I’m can’t seem to get duplex to communicate with my monome 64 using serialosc. First I tested with monomeserial and it worked. Then I edited the monome.lua file, and no dice. Normally I use max/msp apps with serialosc and there’s a “connect” button that automatically configs to the monome.

The monome settings in duplex browser seem to be configured for monomeserial. What steps should I follow to connect with serialosc?

Thanks!

Hey, I would like to know that too :slight_smile:

The new control-maps were submitted by nightmorph, he presumably knows how to use serialosc with Duplex?
Personally, I’m still using monomeserial on my main music machine. Trying to install serialosc right now on the other partition, let’s see what happens :slight_smile:

:yeah: GREAT JOB DANOISE THANK YOU SO MUCH

This is a reply to this post

In Duplex, each physical (or, in the case of TouchOSC, virtual) control can be represented in three ways: state (on/off), color (RGB) and text. So a “compound values” is then a question of representing / transmitting both color AND text as the current state. This is not so hard - the tricky part is to get the hardware details right (make it work across a wide range of gear, while keeping it flexible enough to be interesting.

We could end up with these slightly different features, which are technically related:

1. UILabel. A separate UIComponent which can display a text string (can be configured to one or multiple lines, contain X number of chars, etc.)
The UILabel will facilitate “LCD panel readouts” or just static labels that improve the readability of the virtual control surface (for example, put a label called “DSP devices” next to the Effect application’s device list)
The interface for setting the text should be specified by the device driver (e.g. TouchOSC.lua) - this can vary widely between devices, as different MIDI sysex or OSC message implementations have to be dealt with

2. Compound values. Display button text + color on the device / virtual control surface (currently, we need to choose between color OR text)
If the device supports dynamic text, use the same methods for updating the text as the UILabel

If the device doesn’t support text (the Launchpad, for example), it still represent an improvement for the virtual control surface (add those arrows which are painted on to the hardware)

You mean, because creating a template in TouchOSC is already a lot of work?
Well, control-maps are functional. You can’t skip that step, it is the thing that tell us which parameters are located next to each other (groups), and much more.

Sorry, I don’t understand. You assign mappings through a device configuration. This is as complex and unique as it gets.