hi,
I just updated the svn and with my joy there’s monome support! at least for 128, I have monome64 so I don’t know if there’s a problem with it.
Could you explain how to setup (under linux) the monome? I have already the latest version of serial-pyio and I configured an OSC application but I don’t realize how to communicate with the duplex monome tool.
thanks
ok, seems to work – I don’t remember if I started renoise before or after configuring the serial pyio OSC application, but basically it works with monome 128 matrix+mixer and it handles ‘only’ the matrix (the 64 version that I have) 
Hey kpanic - did you try setting the port numbers, address and prefix? The port numbers are set to 8002 and 8082 as defaults, you probably want to change this to whatever the ‘serial-pyio’ application is set to.
Personally, I use monome-serial on OSX and WinXP, and here I sometimes have to ‘nudge’ the port numbers before everything works. It seems like an issue with the monome-serial program, as other OSC ready software can’t receive anything either, before this little trick is performed. Don’t know if this is the case with the linux driver as well…
Apart from that, the monome class is pretty simplistic. It shouldn’t be monome128 specific either, you should be able to specify a new device configuration simply by adding an additional control-map and specifying ‘monome64’ as the device-display name
hey danoise, no no it works – before I start renoise, then I start serial pyio, I have changed the prefix and the ports and the communication is ok, thanks!
awesome, i’ll give this a go tonight and report back on my experience
Cool! I definitely want a bit more feedback with this whole monome/OSC thing before we launch the next official version of Duplex, so this is much appreciated.
One thing that you should take note of is that, at the moment, there is no support for multi-message format. This is something we need eventually, but since 95% of everything is single-message I have simply put it to the side for now. What this means, is that the monome accelerator support is limited to a single parameter, the same is true for the TouchOSC template, which has an XY control.
Btw: this is what the TouchOSC template looks like - it’s now possible to define buttons with different sizes 
can you please explain the button/leds on the top row of the matrix?
svn revision 749
edit:
i know this is trunk code and could be broken but should the leds change to reflect the matrix pattern mutes?
Sure - it’s very simple. Both are used for paged navigation.
The two leftmost buttons (1 & 2) are for navigating up/down through patterns, number 3 & 4 are for navigating sideways, through the available tracks. Like this:
[up][down][left][right]
Cool, that works great 
, but I find myself getting a bit lost as there is no feedback on the mute status of patterns in the body of the matrix on device.
Having the top row of the matrix reserved for paging obviously only leaves 7 rows left for patterns.
Which is fine, but say when you are working in a 4/4 time sig and using say short 1 beat pattern lengths, a 2 bar loop will overlap onto page 2.
Jamming on the transport in the final column is tricky, but I do like the move to the same line in another pattern behaviour.
Holding one button then pressing another in the final column would be nice to set up a multiple pattern loop?
What about having an option for the paging navigation as a keyboard shortcut or just simply automatic based on transport location.
Taking it off device and having 8 pattern rows?
On the mixer I find myself muting tracks by accident when pushing a volume setting button twice (the volume fader drops to minimum)
Is this intended behaviour when there is already a dedicated mute row along the top?
I’m running a monome 64 so i have been manually switching config to access the matrix and mixer.
Is it possible to tie configs to the global view presets?
So I hit F1 and get the matrix and F3 for the mixer?
All the above really is personal preference on the control layout so feel free to say I can modify it myself if that’s what I want. 
edit: just found alot of answers on the duplex tool comments http://tools.renoise.com/tools/duplex
I think many of your questions deserve an answer here - even if your found answers elsewhere…
If I understand you correctly, the problem is to translate the matrix slot states to a device with just on & off? Remember, the Launchpad has 15 colors to choose from, which makes it pretty simple to illustrate a empty+muted slot, etc. On the monome, there’s really no right or wrong way of doing this, but I found it most practical to be able to distinguish between muted/empty and active slots - you can change this to your own desire, by editing the matrix palette (colors with an average above 0x80 will be lit on the monome).
This is something I’ve got planned - an alternative to the basic slider the matrix currently has. UISeqControl, or something like that…
There’s already a mechanism in place for following the song-position when global song-position follow (SCROLL_LOCK) is enabled. However, it could be expanded to follow tracks as well. Once this is in place, you can simply configure the device to use the entire surface for the matrix (as determined by the controlmap + mappings).
Absolutely - they are two different things. Muting the channel will be the same as telling the instrument to stop playing, but the release and effect (reverb tail, etc) will still be playing. Turning down the volume, on the other hand, will do what it says. Think of it as the difference between a conductor telling a musician to stop playing, or a producer muting a certain track on the mixing console.
By default, F1/F3 are already assigned to view presets in Renoise, but I get the idea, and it would definitely be easy to implement! Even better - to have global shortcuts on the controller?
I’ve figured out that this means by default that if a pattern isn’t blank and is not muted then the corresponding led will be lit.
My initial testing was just with a blank song so I was too early to criticise the lack of visual feedback.
awesome.
track following on the mixer and automatic horizontal matrix scrolling based on the screen cursor would be great.
ok, understood, so long as duplex is set up to control prefx volume i can see the distinction.
The reason I suggested a link between view presets and duplex was that I more often than not I found myself with the pattern editor on screen when using the matrix and with the mixer on screen when using the… erm mixer on device.
So the way i saw it working was that you could navigate to the thing you wanted to use on screen then control it on device straight away, (kind of like the way the a nocturn speed dial knob works but for more controls at once) and was the reason I was asking about something like renoise.app().window:select_preset_observable on the api wishlist thread
when I was building my own monome tool.
Many users may be wanting device only performance so having a button press sequence that wouldn’t normally be pressed accidentally like hold bottom left and press bottom right for config switching right and opposite for left would work too. It could even change the global view on screen at the same time.
Of course people may have altered their own personal global views but you get the idea I’m sure.
Would it speed up the switch by having everything in in one control map xml then offsetting the grid, rather than switching to a brand new config?
thanks for answering all my questions.
Problem with making them observable is that the selected presets right now have no “state”. The presets just recall what you’ve stored before. They are not auto updated when changing the view layout.
Nevertheless you could threat them as if they have states - in the controller only, ignoring changes that are done outside of the controller?
I feel like I have taken this off topic now 
but…
renoise.app().window.upper_frame_is_visible, _observable
already exists so how about making the tabs of the upper, middle and lower frames observable?
renoise.app().window.middle_frame.mixer_is_visible, _observable
or something similar
Notifications could then be called in turn when changing global view presets leaving them as they are.
View presents are more than just this (visible frames). But you can make “anything” observable, defining your own “state”, by observing the stuff on your own in an idle notifier.
more off topic nonsense!
i see what you mean now taktik, about global view presets having no state.
switch back and forth between presets using function keys or UI
or just switch the middle pane tab away from the pattern editor and back
the following code only works within the the pattern editor 
,so idle notifier it is.
function attach_to_pattern_advanced_edit()
if renoise.app().window.pattern_advanced_edit_is_visible then
print("i can see the advanced pattern editor and so can you!")
--change duplex config to matrix
else
print("you've hidden the adavanced pattern editor")
--change duplex config to mixer
end
end
renoise.app().window.pattern_advanced_edit_is_visible_observable:add_notifier(attach_to_pattern_advanced_edit)
Hey I’v just tested the last svn of Duplex with an arduinome 40h (64), it works great.
Just some remarks:
It’s not related to Duplex but I’ve noticed that in matrix configuration when you mute/unmute a pattern, the audio is OFF for the whole pattern duration even with autoseek. On the other hand this is not the case when you mute/unmute the current track.
Does this behavior is wanted by the team? I don’t know if it’s bad or good (I think it’s how Renoise deals with the pattern matrix and audio) but since I don’t have access of the mixer(and mute/unmute the track) with 64 leds, mute/unmute patterns is not really fun in live if you have a long linear track. Maybe the track should be adapted for live performance. Dunno.
Another thing, is it possible to synchronize the led blinking of the current row of patterns with the beat to give a live feeling. I know this could be tricky since some people compose at 400BPM.
I could probably tweak myself the script to do all the things I’ve mentionned if I have some time.
Anyway great job Danoise and Renoise Team!
Thanks for the kind words Arboreal!!
So, what you are suggesting is that the matrix muting could have a mode in which the instrument playing is not stopped, but rather that the volume is turned down? Kind of like, having the “default mute mode” from the preferences section applied to the matrix mutes as well as track mutes?
Somehow I think it would be best if we were able to specify both - so the matrix could have both the current “off” and a new “muted” mode. But then it would be visually distracting trying to put “off” and “mute” into the tiny matrix slots - any ideas on how to solve this?