customizing the layout of the linnstrument.

[zite909]

Dear Roger, Kevin,

Im thinking about getting one linnstrument when it hits the european market. It looks like it is the controller I have been waiting for a long tine !
Im wondering if in the forseeable future, it may become possible to customize the layout of the linnstrument. I mean for instance :
-using the whole surface as only 4 rows to incrase the vertical resolution.
-using one column/row as a ribbon controller
-using one part of the surface as a 2D ribbon controller
-using the lower half as a keyboard and the upper half as a row of 25 midi cc sliders (useful to progamm synth which do not have a 1 knob per function interface)
-....

See you,

[Roger_Linn]

Hi Zite-- In answer to your questions:
1) Each of the 8 rows in separate so you can't slide vertically from row to row.
2) There is a feature called LOW ROW that lets you use the lowest row and a separate ribbon controller. Also, you can enable Channel Per Row mode, in which all notes played on a specific row will be sent on a unique MIDI channel, so you could use the Pitch Bend messages as you like.
3) See #2.
4) As explained in #1, you can't slide a touch vertically across rows. You can however use our CC FADERS feature to treat the 8 rows as 8 horizontal CC sliders. For example, the left keyboard split could be normal play and the right split can be used as there 8 CC sliders.
Please see the relevant section of the online manual to learn about these features.

[lokey]

Roger, while i appreciate the general answer of 'the firmware is open source, have at it', i would encourage you and co. to provide some more explicit tutorials and starting points for the newcomer. Arriving here out of the monome community, i have seen the benefit of providing easily accessible 'hooks' into the interface, in terms of controlling the lights, or implementing a 'user' mode to expand the utility of the device while maintaining the existing feature set.

For example, if i were to be interested in replacing the functionality of the 'preset' button (i use ableton and program change messages dont offer much utility within live), or to modify the default led schema to show and distinguish between major and minor scale notes, its difficult to see exactly the best method to proceed. Im not asking for real hand-holding, but it would be nice to see a roadmap to proceed from.

Similarly, looking through the firmware code, there are occasional mentions of 'white' amongst the led colour options, but for the most part colour-usage has been restricted to the ones we see at play in the existing firmware. Was this a power-draw related restriction, or for some other reason?

Anyhow, just wanted to say how much this instrument intrigues me, and congratulations for bringing it into the world.

[Roger_Linn]

Hi Lokey,

Have you seen the midi.txt file in the source files? That details the NRPN MIDI messages used to remotely control all LinnStrument settings, including the note lights.

Regarding tutorials in editing the source code, to be honest it is common practice in open source projects for programmers to learn the code from the comments and our code is pretty well documented. The assumption is that anyone who wishes to modify the code knows enough about coding to be able to learn what is needed from the comments or from others in the community. I appreciate that you're a newcomer to coding, but the problem is that we don't have the resources to provide that level of training in coding. Perhaps a programmer on the forum would be willing to offer help? Using your example of modifying the function of the Preset button, a programmer should be able to find the button-handling routines and trace them down to where the Preset button is handled.

The above said, one alternative to implementing quick changes between major and minor scale lights would be to do what pianists do-- use the normal C major scale lights but simply start at D (for the lit Dm scale) or A (for the lit Am scale). Another alternative is coming in the next software update-- 4 "total machine state" presets, permitting you to instantly change all settings in LinnStrument at once.

Regarding the white LED color, yes you're correct in that we didn't implement it because of the power drain of a 3-LED color. But also, because the red/green/blue LEDs have unequal brightness, the white is not really white anyway so it wasn't so useful.

Thanks for the kind words about LinnStrument. I love playing it myself and don't touch my guitar anymore. NAMM was a blast for me because I got to stand there playing LinnStrument for 4 days.

[gbevin]

Quick addition to what Roger said, we have an introduction tutorial video for coding LinnStrument that I recorded at a conference a few months ago. Some minor things changed, but it should still provide a good overview and starting point: http://youtu.be/iENVztlxWuk

[lokey]

thanks all, its not so much that im a newcomer to coding (ive done a fair bit of python and max coding over the years developing applications for the monome), as it is a desire to see a little more dialog about the underlying limitations of the sensor and display aspects of the device, so as to encourage more active development for this platform, to focus interface development in areas which are appropriate for the hardware.

Following the code is straightforward, as it is certainly well commented, but such decisions as the lack of white, or the limitation that 'you can't slide a touch vertically across rows', are difficult to comprehend without some further dialog from you folks about the reasoning behind them.

Another question then, with regards to this '4 machine state presets', if one such state were to be set to 'unlit' for all pads, then 'painted' using incoming midi messages to display the a new user interface, would these light-states be maintained when toggling to different presets and back to the user state, or would the surface return to an unlit state? In other words, does the display interface need to be hard-coded into the firmware, or is it sufficient to set it to 'unlit', and then use a burst of midi messages to define the interface when the patch is first loaded?

anyhow, all the best, thanks for taking the time to interact.

[lokey]

also, with regards to my question of 'minor and major' scale lightings, i may have not made myself clear. Im not interested in simply changing which notes are lit, but in changing the display colours to be non-boolean, to represent notes that are shared across a wide range of scale modes, for example to highlight notes which are shared by the c minor and c major scales in one colour, and use a second colour for those that are unique to the minor, and a 3rd for those unique to the major. anyway, i appreciate that you folks want to focus your efforts on your own projects, and your own vision of how the hardware is best used. I just thought it might be helpful to discuss possible directions of development, and identify the 'low hanging fruit', so to speak.

[gbevin]

About the 4 presets, any changes that are available through the panel UI will automatically be stored. Arbitrary lights and colors that are set through the MIDI API will however not be preserved, so it will return to an unlit state. Thanks for mentioning this, since I just realized that I forgot to provide a MIDI method to change presets. Sending a burst of MIDI should be sufficient.

[lokey]

hmm, the trouble there is detecting when a preset has changed, and communicating that back to the patch. Without that, preset toggling isnt very useful as a 'user' mode...

for example, if i want to play a midi sequence into a looping buffer, then switch over to my own patch to manipulate the playback of that buffer, then switch back to the standard midi play mode to overdub, and then switch back to my own patch again, i have no way of 'repainting' the interface at the appropriate time...

[gbevin]

hmm, the trouble there is detecting when a preset has changed, and communicating that back to the patch. Without that, preset toggling isnt very useful as a 'user' mode...

Yes, I was thinking about that, but I can't think of a good MIDI message to send to notify about Linnstrument preset changes. Intuitively it would be program change, but in reality that can't be used since it has a true musical meaning. RPNs can't be used either since if the target is not expecting them, they'll be seen as regular CC messages, and I don't think we support sysex in the MIDI chip.

[lokey]

is there no way to simply store the lit-pad grid data, internally? so that switching between presets also recalls the lighting states?

[gbevin]

We have a very limited amount of data storage, I haven't calculated the use recently, but I want to focus on using memory for features that would be used by the majority of users. Individual programming of lights through a remote MIDI API and wanting to store this is probably not going to be used by many. That being said, your best bet is probably just implementing this in C with your custom firmware version.

[lokey]

thanks for your time, although i suspect that any customization will run into this issue, so i suspect its actually a larger population than you may be expecting. As i said, i think that providing a direct hook into the existing firmware will be much more powerful than expecting folks to completely implement their own firmware changes for every use case...


when you have a chance, it would certainly be helpful to document data storage limitations, again towards establishing a clear understanding of the limitations of the hardware....

[gbevin]

The platform limitations are those of the Arduino Due, those are all documented at the Atmel product site.

[Roger_Linn]

Hi Lokey,
You can also learn more about the Arduino Due circuit and its parts, including schematics (which we use in LinnStrument) at arduino.cc.
I'd like to clarify that if there's a programming question about LinnStrument that isn't answered in our source code or the Arduino Due documentation, we'll of course be happy to answer it, though we kindly ask that you help us out by trying to find the answer in that documentation first. The problem we have is that my company consists of only me and as of this week, one helper, and Geert's work on LinnStrument is in addition to his full-time job. So our resources are limited. Our decision was to focus LinnStrument's operation on its core competency-- as an expressive musical performance instruments--and not make it so complex that it scares away less technical musicians. And recognizing that such a new idea will be used in a variety of ways by many people, and that we can't possibly implement all the features that each users might want, we opened up the source code.
By the way, can you tell me (by email if you prefer) which LinnStrument owner you are?