Roger Linn Design

Jaself · Post by **Jaself** » Fri Jan 30, 2015 1:05 am

Hello LoKey! You bring up many interesting questions and ideas that I (just another user) would very much like to follow up. Ideas from Monome and the potential of using Max with LinnStrument are two areas I would like to learn much more about.

I have started on a path of learning to customize LinnStrument firmware aiming towards more interesting dynamic use of the lights and display modes and additional MIDI capabilities. You can see some of what I have been up to on GitHub in my fork of the LinnStrument firmware.

I am glad to discuss and share questions, ideas, observations, and solutions and would like to help in building up a community resource oriented towards getting the most out of the LinnStrument firmware and MIDI control of it's features.

User accessible hooks, user mode, road map - Yes, these are great ideas! As Roger pointed out and as Tim Thompson's previous post demonstrated, there are hooks in that much of the user interface and, of course, the lights are controllable via MIDI. As I think about customizing the firmware to add new MIDI controls, new display modes, new note mapping, and other features, I encounter major questions as to where to put my code so that it will not conflict with the main functionality or where it will not be clobbered by coming changes to the standard firmware.

Expanded/custom presets -
If not PC, what would be useful for working with Ableton?

More color choices for LEDS - I would really like to have more than the seven paintable LED colors currently available. For me, they would not have to be nearly so bright as the current colors. So perhaps it could be done without excessive power requirement

MIDI control of lights, modes, settings, etc - much more in the way of advanced and custom features could be controllable via MIDI than could be easily implemented in or represented by the standard onboard user interface. One (or preferably multiple) user modes could greatly help in providing a place for users to customize and add features to their Linnstruments.

It would be really great if one could select a user mode or full display via MIDI or otherwise and then paint the LED colors on it as a separate identifiable display and have that display be saved and restored as you switch to other modes and back. Or to be able to paint to it off screen or to copy LED states from one mode to another.

Jaself · Post by **Jaself** » Fri Jan 30, 2015 1:51 am

Responding to the original questions on this thread from Zite909, it seems to me that using the channel per row mode (as demonstrated by the post from Tim Thompson) would answer all questions affirmative.

Since channel per row mode would identify the unique grid position of any touch, one should be able to translate the MIDI messages from touches in a given column (whether discrete or continuous sliding up and down) into a continuous range of vertical controller positions.

Roger, when you say that one cannot slide a touch up and down across rows, I assume that you mean that there are some gaps or variability in the values returned that are difficult to smooth out or to execute the logic quickly enough for performance. Please clarify.

Jaself · Post by **Jaself** » Fri Jan 30, 2015 4:31 am

Regarding Lokey's request for an additional set of notes per octave to highlight with a different color, such as for highlighting the notes in either C major or C minor while distinguishing the ones in common from the ones that differ.

Within the global settings mode display, in the first column, after main and accent, there is room for another selector for a 3rd or 4th group of keys to choose in the same way. It would be very easy to implement. It would need a new GlobalSettings property (like boolean altNotes[12] perhaps), a new SplitSettings attribute (something like byte colorAlternate or byte colorAlt perhaps), and a slight extension to the colors selection column in the split settings mode display.

You can see most of what is needed for this in the extensions I made on my fork of the firmware code implementing a separate color for middle C (colorMiddleC). I didn't implement a selector for middle C since I want that as an absolute reference independent of per octave highlighting.

Recent updates to the firmware have a brief blinking of the middle root note (according to the accentNotes setting, not necessarily middle C) that happens on the transition between certain display modes.

The brief blinking is a little too subtle and transient for my preference, but the two ideas could be combined with a notes selector like I suggested above for altNotes.

Jaself · Post by **Jaself** » Fri Jan 30, 2015 5:33 am

gbevin wrote: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.

A roadmap or even a rough outline of some of the exciting new features you have in mind would be very interesting and useful and helpful to those of us thinking about advanced uses and customization of this wonderful new device.

It would also be helpful to know how much memory is actually available for storing alternate display states and other interesting data.

Following the inspiration and examples I found in your promo display code, I have implemented several kinds of animations of the lights in my custom firmware, including
Conway's Game of Life. This has led me in the direction of maintaining my own version of the display state and contemplating setting up several more.

It would be good to know if I will be running out of memory space very soon. The feedback I get from compiling the source code suggests that there is quite a bit of free memory for the kind of things I imagine doing, but I know very little about this programming environment beyond what I have learned from following your code and examples.

gbevin · Post by **gbevin** » Fri Jan 30, 2015 12:47 pm

When compiling it gives you an estimate of the memory use:
Binary sketch size: 84148 bytes (of a 524288 byte maximum, 16.05 percent).
Estimated memory use: 70232 bytes (of a 98304 byte maximum, 71.44 percent).

So static code memory is only 16% full, however the run-time memory is already at the high side, 71%. Any feature that will add memory pressure will have to be carefully considered before it becomes part of the standard firmware, since once it's in, it can't go back out and something else in the future might require more memory.

I'm very reluctant to publish a roadmap, since most users read that as a promise, and many features are an unknown that could be cancelled during development since they might not pan out. I've had to deal with this for other products, and sadly publishing a roadmap is almost always more frustration and trouble than it's worth.

gbevin · Post by **gbevin** » Fri Jan 30, 2015 12:51 pm

It's great to hear ideas for improvements and I love to see how motivated all of you are. However, we've been working at turbo speed for a long time to get the LinnStrument to its current state, and we're still working on the details. I would like to let it settle for a while, see how a larger user-base picks it up, which other feature requests come in, then work on the most important ones and new ideas of our own. While more light-related capabilities could be cool, there are many other ideas that would be much more interesting musically, and the LinnStrument being a musical instrument, those are more likely to have a lasting impact.

gbevin · Post by **gbevin** » Fri Jan 30, 2015 1:54 pm

Another part of the memory is the internal persistent flash storage, and I still have to look into how much is available there. It will require reading through the code of the third party library that supports data storage there.

Roger_Linn · Post by **Roger_Linn** » Sat Jan 31, 2015 2:56 am

To Jaself--

If you wish to learn what features we're working on, you're welcome to read the descriptions of each change to the source code.

Also, I'd like to say a bit more about why we add certain features and not others. LinnStrument has the potential to be many things to different people, so we figured that many people would want to pull its development toward their personal needs. But my preference is to focus on features that are important to its core competency and design--an expressive musical performance instrument-- and to avoid the temptation to add many features that might scare away non-technical musicians. Also, we don't have the resources to develop every feature for everyone, which is why we opened up the source code.

Another thing I should mention is that we plan to make a smaller 16-column model, which is why the printed panel parameters don't exceed the 16th column. So there's almost no space to add new parameters to the first 16 columns. That said, I think the existing parameters fill all important needs for an expressive musical performance instrument.

lokey · Post by **lokey** » Sat Jan 31, 2015 7:45 am

hi roger, i dont own a linnstrument at the moment, am looking to purchase one when you start shipping to canada. just trying to come to grips with the framework and the philosophy of the device. thanks for your time in answering my questions.

hi Jaself, nice to hear your ideas! we'll have to keep this dialog flowing, there are a number of existing monome apps im keen to port over, i think sample manipulation is going to be very interesting, having a finer gradation of control over buffer location with be an interesting development of previous grid-based interaction.

as to the dichotomy between the lights, and the instrument, i suspect thats something of a false one. led feedback is a huge aspect of flexible instrument control, in my experience. having feedback which indicates the state of the sound, and the state of the instrument, are very important, especially when controlling a variety of instruments over the course of a song.

Jaself · Post by **Jaself** » Wed Feb 04, 2015 4:07 am

lokey wrote:hi Jaself, nice to hear your ideas! we'll have to keep this dialog flowing, there are a number of existing monome apps im keen to port over, i think sample manipulation is going to be very interesting, having a finer gradation of control over buffer location with be an interesting development of previous grid-based interaction.

Thanks! I agree. Please give me some links to some of the things that you have been working on and thinking about, especially those that might apply to LinnStrument.

lokey wrote:as to the dichotomy between the lights, and the instrument, i suspect thats something of a false one. led feedback is a huge aspect of flexible instrument control, in my experience.

Having the lights as a reference to the location of musical notes on the playing surface was a major part of my original attraction to the LinnStrument. It makes a huge difference in the ease of learning.

Having played with it awhile, I begin to see other possibilities that I am excited to explore.

Roger_Linn · Post by **Roger_Linn** » Wed Feb 04, 2015 4:19 am

Hi Lokey-- we've just started shipping to Canada, though I have yet to update the online store.

griotspeak · Post by **griotspeak** » Fri Feb 06, 2015 4:58 pm

Howdy lokey. If arrangements need to be made (acquiring a Linnstrument), I am not averse to assisting a fellow monomer, especially one of such esteem

lokey · Post by **lokey** » Sun Feb 08, 2015 3:20 pm

hey thanks griot! high praise!

its been too long, ive kept my head down lately, actually making music instead of coding interfaces, but ive been feeling like its time to return to tinkering

good news about canada shipping roger (and free too, thats a nice touch), just in time for my birthday too

just waiting on a new surge of finances and you'll be hearing from me, maybe the can$ will have risen back a little closer to parity (damned petrodollars are almost as unstable as bitcoin these days :p).

lokey · Post by **lokey** » Thu Feb 12, 2015 1:12 am

hey jalsef, here's one example of an app i intend to port over, once some degree of user customization/preset control becomes established: my smplr monome app, a flexible groove~ based grid looper/shuffler for live recording and recomposition. i look forward to adding continuous sample repositioning/scratching using a delta approach on the pitchbend data. id hoped to also allow for sample morphing by slides across rows, but it sounds like the sensor limitation may make this infeasible.

http://monome.org/community/discussion/ ... 12#Item_76

Drehleierguy · Post by **Drehleierguy** » Sun Mar 29, 2015 3:14 am

Hello all,

Thank you for this VERY enlightening thread. My finger is hovered over the 'buy' button, but my main interest is in how the instrument can be used in various custom applications, likely via MAX. I gather that there are as of yet no libraries that would lubricate this process?

I am a musician with limited ability in programming, but I'm willing to work on it as needed! I was leaning heavily towards the Push for a particular project, but of course it has its own issues regarding programming and use. And the Linnstrument is so very very interesting for so many of its own reasons.

I'm especially excited about how it can be used for playing in non-twelve-tone scales...

I'll be watching developments here eagerly as my finger gets ever itchier over this 'buy' button.

Regards,

ben

Roger Linn Design

KVR Audio

customizing the layout of the linnstrument.