help improve setup instructions. tell us your experiences!

  • hello dear community!

    it may have been a long while coming, but we are well into the process of refreshing the monome grid functionality and eager to improve in areas that may have lacked a little depth and clarity in the past. there's a number of aspects to this, but one main element is the setup procedure with a particular focus on first-time users.

    many years have passed since i experienced the first-time user blues, so it would be great to hear from you where your experience went wrong, how you were helped and what could have steered you in the right direction more quickly. over time the setup instructions have been modified and updated but it seems the goal of minimalism and directness has left some users feeling frustrated with the lack of detail. personally i see the instructions and i think 'great! it's so simple!' but many folks haven't had such a rosy experience.

    there's a new installer package on the way for osx & windows at the least, but any feedback you can give will help focus the process & instructions to those issues that are hardest to get around. so please, tell us about your experience, and bestow your wisdom of how to improve!

    see here for the current setup instructions

    thank you all!

  • dear galapagoose,

    i think it's not the initial setup that puts monome beginners in trouble. i just followed the MacOS setup instructions and got the monome running with the monome test app. But this is where the challenge begins. The monome grids and arcs are no plug and play devices so as an unexperienced user and programming noob it's not obvious at all how to get started. one should definetly bring some motivation. then you have to understand that there are different apps for monomeserial and serialosc. then some apps will only work with older max versions. then it's really pretty challenging setting up and understanding complex apps like pages. then it's not hassle-free to get it connected to ableton…and so on. last but not least most monome apps lack manuals.

    the good thing about it is, that you really have to rethink your musical approach through a device that can be/do everything and nothing. the steep learning curve forces you to stick with an idea until you sort it out. and, most important, for any question you have one of the most beautiful communities i know of. people are friendly and patient and reply fast and never snotty with a big heart for rookies. at least that's what i experienced. you sir for example answered some of my beginner questions :-) thank you all! keep up the good work.

  • this is really going off on a tangent but I always think it wrong headed to consider anything to do with monome beyond the hardware design as "minimalism".

    beyond the hardware is just the glorious chaos of open source software and apps, at least from a users perspective anyway.

  • that said - there has been a sterling effort to build and refine the wiki resources in the last while. hats off - great work there.

  • thanks for the positive responses – it's heart warming but unfortunately doesn't let us progress very quickly!

    a couple of points i'd like clarification on:
    - 'one should definitely bring some motivation', indeed! this should be the first line of the setup docs.
    - what does a 'plug n play' device mean to you? could the grid/arc be one without sacrificing it's capabilities?
    - what would you need to read to make it 'obvious how to get started'. this is exactly the point we're trying to improve!
    - agreed about manuals! the wiki page has often tried to act like one, but they are often left nearly blank.

    - i don't believe bonjour print services are required for the standard windows install. i was surprised to see it added back to the setup page.
    - sosc 1.3 was added, then mavericks broke it, so we reverted.
    - can you be more specific about "and other confusion..." – would be great to remove 'any' confusion.
    - i don't think it's wise to wait for multiple OS updates. we just need to test quickly! the forum helps.
    - provided the current sosc is known working on current OS's should we need to refer to old versions?
    - i disagree that we should fill the setup page with this info. we want the setup page to be a super easy process to work through, not an encyclopedia of every problem users have ever had. there's a 'troubleshooting' page which is a bit bare. would be nice to put some of this info there. an faq style thing could help.
    - we'll have a look at the uninstall option for the new installer package.
    - wiki's are, by definition, collaborative & user contributed. i don't want to talk down to our audience.
    - agreed that we need to encourage people to edit the wiki more. maybe not first time users immediately. would prefer them to get it working & make something with the device!

    and some general thoughts:
    - i'm tempted to hide almost all references to monomeserial. we made a big effort in the last months to update the useful apps, and monomeserial apps are off the main apps list (no complaints yet!).
    - i can't think of any reason for a 'new' user to have to learn what monomeserial is/was and shouldn't need to use it.

  • it might be daunting because of all the variables
    but, a video "tutorial" would help

    i dont remember the instructions being confusing or vague (tho i experienced some frustration trying to get everything right)

    if there had been a simple clip showing a user go from nothing connected/downloaded to fully functional...that would have been easier to follow

    at least for me

  • point taken. we'll make a video.
    still think there's a lot of room for improvement on the actual setup process side though...

  • i'm eager to see if you can make it even easier but its better than i remembered

    get ftdi
    get serialosc
    get max
    move serialmaxpat

    i guess hurdles arise if you're not sure which ftdi, max, or serialosc to get...or if you forget to move the maxpat into the correct folder

  • for windows 7 bonjour print services is needed, i sold my 64 a couple months back and the guy who bought it and myself spent a couple of days scratching our head since the windows instructions didn't mention it, brian added it back in because of this thread i think:

    when you run into trouble with windows there is a link to troubleshooting instructions for OSX: .. not very helpful

    i think what any new user needs (at least what i needed when i got my first one, what my friends needed when i borrowed them a monome and what the guy who bought my 64 needed) is:

    A/ an plug n play installer ... not hunting around for different things

    B/ an introduction video explaining what the monome is and give a few examples of what you can do with it ... not wading through hundreds of threads and obscure performance videos to figure it out yourself

    C/ a manual .. not wading through threads .. a short concise instruction and overview of the technicalities and basic procedures .. doesn't have to be long but more than just a bulletpoint list and should be clearly understandable to even the less technically savvy ... when you never used a monome things like serialOSC or monomeserial or even MAX patches might mean nothing at all

    D/ a bundle with a set of example apps, a selection of the most popular and well working apps that can get the novice user started .. and a clear path to it. At this URL for example: personally i would expect a manual (see pint C/) , the newbie would be a bit overwhelmed with the Mark Eats Sequencer or mlrv i think ... maybe something more simple like an intro explanation and some simple apps showcasing/explaining the functionalities would be better at the root of the documentation

    E/ give a short intro on MAX and the technical implications or how it fits together with the monome, i remember cursing for weeks trying to figure out the whole cycling74 folder structure and prefix/address things ... i have also had many problems with different versions of Max having different folder names fuckin up things, so maybe a troubleshooting guide with things to watch out for would be helpfull too

    i love the monomes (bought 3 over the years after all), what i always loathed was the confusing technicalities of it and lack of proper, centralised documentation and support ...

    i think a series of videos like the NI Maschine tutorials would be also nice .. explaining what the monome is, what you can do with it and a series of example workflow videos

    i think it would be great if you guys remember that maybe there are simple, stupid musicians (like myself) who might want to use a monome ... people who want to play the monome in ways similar to a guitar, piano ... not everyone wants to look under the hood, rig theyr own nitro injection and reprogram the gps .. some people just wanna drive :)

    EDIT: here's a good example of what winds me up: i've been with the monomes for nearly 5 years now and still run into basic/primitive setup problems like this ... just wanted to quickly check if i could still use molar with the newer DAW versions and serialOSC ..and here i am half an hour later bustin my balls and posting 'help me' threads like an idiot .. not nice ...

  • edited: meh, it'll fix itself

  • @galapagoose: "monomeserial apps are off the main apps list (no complaints yet!)."

    then here is your first official complaint about taking monomeserial apps off the list: molar is missing and i violently complain !! one of the absolutely best apps ever made for the monomes .. gone ... pfff ... the molar thread was the most active thread of this community for years, had hundreds of pages if i remember ... IMHO still no other app that has such an elegant and powerful midi sequencing functionality ... i still run it on my old macbook with monomeserial and live 7 ... killer app if there ever was one

    also never understood the need for serialosc (from a pure idiotic musican users perspective) ... with monomeserial it was all good for me, was using a ton of applications without problems .. then serialosc, zerconf and whatnot came and using the monome became a pain

  • discopimp said: "serialosc, zerconf and whatnot came and using the monome became a pain"

    agreed. i still use monomeserial on my machines. could never get serialosc to work neither my macbook running leopard nor windows machine.

  • a suggestion: do not use max/msp in the examples on the monome setup pages.

    instead provide a super-simple platform independent test application. this application should not make sound. it should simply show connected devices, visualize button/encoder states. it should also be possible to set led state in order to test a devices that has been setup.

    of course max/msp is widely used and most monome apps are made for this environment. but keep the max/msp setup/intro separate from the core setup.

    pd, supercollider user here.

  • @jah good point

  • @jah: i agree (somewhat.) when i looked at the setup instructions for linux and saw, "install max/msp under WINE" i literally thought this was a joke! (anyone attempting this: good luck... dark waters. ) in comparison, my first step in testing a grid on linux goes something like:

    > ls /dev | grep USB
    [ returns, say, '/dev/ttyUSB0' ]
    > xxd -c1 /dev/ttyUSB0

    ... mash buttons and see bytes. bytes being sane, move on to whatever environment will actually use the device. this may or may not mean using a serial/OSC bridge at all...

    ( of course, most of the time one probably does want to use serialoscd, and that part of the linux setup guide worked perfectly! so thanks to @nightmorph et al for that. it's worth pointing out here that the one line i found inaccurate for my setup, i was able to simply edit the wiki accordingly and add the information. anyone can do this. if someone with a talent for technical writing, wanted to accurately restructure information for clarity, i'm sure that would be appreciated as well! )

    but one point is that the idea of a plug+play installer is not so easy. there may be literally nothing to install, or maybe you want to use someone's max patches, with all the associated dependencies... maybe you will always use the same dumb serial interface, and maybe you want to hotswap random devices with cross-platform OSC-based software (then you really do need zeroconf / serialosc.)

    anyways i don't want to get too involved on this topic... it seems like an emotional one, and i clearly represent a minority use-case. (if you ask me, all is really obligated to provide is the serial protocol. the rest is bonus.) but it is one perspective!

    and of course i'm being a little facetious here too. obviously one wants an immediate and rich musical experience with a musical instrument. this is a challenge when your idea is to make as few assumptions as possible about the structure of that experience. so, it is tricky and hopefully it gets easier with time... but sometimes flexibility leaps ahead of ease.

    ps: raj, i think your monome+supercollider tutorial is really awesome. clearly a labor of love and surely very useful for beginners or the curious. it is a perfect way for a monome user to learn SC! but, come now... "concise" ? :)

  • I have a 40h from kit (circa 2008) and have worked through max 4.6 5 and 6 as well as monomeserial and serialosc on Win XP on the same early noughties wintel boxes. I have been through the setup process several times.

    It's been one of the techier things I've had to do to get an electronic music gadget hooked up, and it still is. It's also a bit greedy: you can't run a monome and an arduino gadget, the move to serialosc closed down the analog functionality in the kit board and you can't let the computer go to sleep IIRC - so it kinda hasta deliver. Folks, please correct me if I'm wrong: this is based on my recollections of the last time I did much with the device, and I'm not in test mode at the moment.

    The current setup page is generally OK. It gets you there and the process seems to work, but I can see it would be daunting for a new or potential user. It's not for the faint of heart.

    If you snit a hag on installation, then the forums are not a good reference source: hard to navigate, and filled with contradictions.

    * Do not put beta on the setup page: I can see situations where that works (IRCAM forums for example), but I think it's fair to say that the monome is sufficiently productised that you want to have a very low fail rate on getting up and running, so the community can devote its energy to inventing groovy new things to do with it. The monome is mature enough to aspire to this.
    * The standalone test app idea is cute, but I'd rather have a Max object. Or a Human Interface Device wrapper.

    There's getting a valid install, then there's getting you up and running. I think that we should consider this crucial next step:
    * The learning curve is steep and frankly distracts from any musical experience: a crib sheet for how to deal with OSC would be a boon perhaps an overview of the different strategies adopted in some of the more popular apps; I'm OK with Max, I'll get my hands dirty with C, but network protocols are another planet altogether.
    * It might be worth establishing a standard tool chain for 'driver' development. If the windows one was MS VC++ 20YY & redistributable, that would be fine.
    A standardised tool chain for hacking the controller in the grid might be worthwhile.

    Have we really eliminated the need for Bonjour? I'm sure I tried that option when serialosc 1.2 came out and had to put it back on again. It works without zeroconf though.

    Gotta go now, but good luck with it.

  • what if serialialosc itself had a test option? to just establish a key->led loopback, print traffic to stdout? seems easy to implement.


  • @discopimp:
    firstly thank you for writing your thoughts in such depth! but still a few things:

    - we definitely need to expand the troubleshooting page. if you have explicit suggestions of what that could be / should entail please write them here, or you could even add directly to the wiki page (

    - can you please describe a ‘plug n play’ installer? we can’t legally distribute max with the installer. what items did you have to hunt for (apart from bonjour, sorry!)?

    - a video is a great idea. do you have any links to videos that are a good example of this? i’ve always found watching these things tedious, so curious what people want to see in this context.

    - manual: i appreciate those things you mentioned, but i think we probably need a whole thread dedicated to what the manual should include. monome isn’t based around a software daw, so it’s hard to have a ‘relevant-to-all-uses’ manual. if you want to add more specifics, i started a wiki page here:

    - we’ve got a ‘bundle’ in the works right now (soren’s sitting in front of the fire coding). it will be simpler than mlrv or mark eats. it will be expandable once you get it, so it can remain useful. we’ll make videos performing with it, and explaining how to use it. we’ll make a manual.

    - how should we best provide ‘clear paths’ to the appropriate content on the wiki? by it’s nature there is a huge amount of information, and with all large repositories of information, organisation is the most important part. we can improve here. please help us with specifics of what could be moved / restructured.

    - we’re attempting to automate the installation of serialosc.maxpat files so you shouldn’t need to worry about it in the future. still a max & monome introduction seems to make sense. what are the main topics this should cover?

    - can you link to the NI maschine videos? obviously we don’t quite have the workforce of NI to implement this stuff, but try our best! monome is 100% open-source so i guess the intention is that a great deal of this info / help is provided by the community. nevertheless we will do our best to help, but it might take a while to get to these videos.

    - agreed that we need to be more conscious of the simpler use cases, where you just want to make sounds. i think the challenge here is that the monome tries to service users from plug-n-play to maxmsp apps and on through c-apps and embedded solutions. no mean feat!

    - re: monomserial apps. they are still there don’t worry. they just aren’t on the front page. there is a link right at the top of the apps page.

    - molar presents a difficult situation. the developer is no longer interested in developing it, and it was built for a many-years-outdated monome setup. it’s like your favourite app that only works on windows xp - what to do!?

    - no maxmsp: this is an often discussed topic around here. everything is built in max because that’s what brian can develop most quickly in. it’s also the most highly used environment for monome applications by a factor of at least 20:1. it would be great to decrease our reliance, but i feel like the setup docs might not be the best place to start?

    - a super-simple platform independent test app would be great. the reality is this would take weeks of development, and results in one more application to write a manual for. we’re still stuck having to explain maxmsp to 95% of users though?

    don’t mean to shoot down your idea. i really like it. i’m just very conscious of how long application development takes, especially when using an unfamiliar environment. however, for someone willing, this could be a great community based development project.

    indeed you’ve hit the nail on the head – users all have different goals with the devices and differing levels of intended commitment. indeed that person with a talent for technical writing would be showered in praise if they were to help out here!

    any thoughts on how we can continue to make as few assumptions as possible, while still allowing the thing be easy to use is highly appreciated!

    - we’ll fix the arduino incompatibility issue in this new release we’re prepping.

    - the analog functionality is difficult. brian doesn’t have a device here for testing any more, but perhaps we can wing some support of the old docs??? it’s difficult to know what to prioritise when some elements have a user base of only a handful of users. obviously backward compatibility is a big issue though, particularly when thinking of sustainability.

    - perhaps it was kit specific, but you can now definitely sleep your computer with the device attached without any problems.

    - what is it about the setup page that is daunting? it very clearly describes a few processes that don’t seem very complex to me? what am i missing?!

    - agreed the forums aren’t a good reference. that’s why the wiki exists. how can we encourage people to add their findings / experiences to the wiki in a useful way? it would be a full time job combing the forums and transcribing things into the wiki.

    - i don’t believe there has ever been ‘beta’ downloads on the setup page. there has been some cases where releases have been pulled due to bugs, but they weren’t knowingly beta.

    - what would a ‘max object’ or ‘hid’ look like to you?

    - crib sheet: this sounds nice, but i’m not sure if you’re talking about general user case, or the budding developer use case? what are the ‘different strategies’ you describe?

    @zebra (again!):
    this sounds nice, but as always, the hard thing is how to run it? i guess it could be open until the device attached to an app. i’m not sure how difficult it would be though. i have a weird feeling that if people are able to turn knobs / press buttons, and see lights, they might be freaked out when it doesn’t make any sound or send midi anywhere?? (“why is my device running in a ‘test’ mode - i just want it to send midi notes”)


    phew! thanks again to you all for your thoughts. there’s lots of interesting points and they’re really helpful to focus the update & refine these processes.

  • well, i guess i'm just missing the point. on linux i have to explicitly call 'serialoscd' when i want to use the device with OSC, or put it in a startup script. so it would be fine to call 'serialoscd --test' instead, or whatever, when first setting up an installation.

    but, looking closer, i guess on osx it's supposed to be an always-on kernel extension. (i don't use it on my osx install, i use monomeserial and a nasty ecosystem of SC classes that manages .conf files. oy. that machine is now too old to even install mavericks, apparently.)

    so ok, whatever, guess i'll shut up now. just to point out that a loopback and print within the daemon seems pretty dang easy to do, and anything else seems like an extra layer of whateverness.

  • @galapagoose

    tl:dr I think the setup page is OK, but the process is relatively fiddly. Since there's more things to install and set up than is usual for music hardware, there's more opportunity for things to go wrong, and that's the real gotcha.

    * Arduino compatibility - \o/
    * Analog functionality - arduino compatibility will work around that, although it's less elegant. What it came down to was trying to recompile 40h.dll (or similar) with the full analog functionality turned on. Since my C experience is minimal, it was a confusing experience. The mingw based toolchain I started with didn't help, but I may give it another crack on MSVC++ anywho - I accept that sorting that out is not such a priority.
    * I'll go back and check the sleeping thing.
    * Maybe I didn't put it very well: what I meant was the set up process *looks* daunting. There's three discrete things you have to do, and two of them are fairly off-piste, to wit, an Apple printer doodad and the FTDI driver (and you have to get the right one). The good news is that the set up page does guide you through the process pretty reliably.
    * Adding findings to the wiki - gee, I'm not sure I feel qualified to do that :\
    * Beta downloads - maybe I misremembered - there was certainly a kerfuffle around the release of serialosc 1.2 maybe it wasn't the set up page - my bad
    * Max object... maybe not an object, but a single encapsulation... my way in is through hacking the test patch, so you could stick with that, but it could be more refined.
    * A HID such as a joystick or gamepad shows up in Max and can be accessed via the 'hi' object, ditto PD. It's easy to route button pushes, it's fast, and the analog is higher resolution than MIDI. Wintel boxes and Macs all accept HIDs, though sometimes a driver is needed. The downside may be that you can't control the LEDs with it, but since they accept haptic feedback for 'rumble' motors, I'd have thought it might be possible.
    * 'different strategies' - erk, rumbled - I was guessing.

    Thanks for your patience, and I hope I said something helpful.

  • @galapagoose

    sorry to not be more helpful than that, to be honest it sounds a bit like although you acknowledge a lot of things people suggest there's always a but coming .. i tried to make it as clear as i could without writing a novel

    and now i'm gonna say something that's been burning my lips for many years now and is probably not going to make me a very popular guy:

    do you work for monome ? are you paid by them to do this ? why isn't monome/brian/kelly finally properly sorting this out ? why is there not even a word about this from them here in this thread or this one: the latter one being a good example: a new guy comes in and nicely/politely asks some really relevant and interesting questions ... what does he get ? fuck all and some smug attitude from the reverend godfather stretta .. brian just hops in to defend the tenori-on .. nice one ...

    i have a pretty good idea how many grids monome has sold over the years and having worked in marketing, product design and manufacturing also a pretty good idea of the revenue that generates .. i think not providing adequate documentation and letting the 'community' sort it all out is unacceptable .. having such a crappy forum software with a totally useless search is even more unacceptable, especially considering we have to sort everything out by ourselves

    so forgive me if my above posts is as far as i'm gonna go with this, i really don't see why we/me/us should be doing the job of a for profit company .. open source does not mean not for profit and monome is not an NGO solving world hunger as far as i know, i'm not saying Brian and Kelly are on their yot in st tropez sippin champagne, but for sure the grids have generated enough revenue and profit to provide adequate install and config software and a proper indexed search engine and documentation section for this site

    but to boil it down once again .. a monome should:

    come with an installer, a manual, a proper standalone configuration utility and some sample apps, and proper support for new users in terms of video tutorials and appropriate online threads and additional documentation and troubleshooting tips/procedures .. just buy almost any modern electronic instrument and take your cues from there ...NI Maschine is a good example since also a bit unusual to wrap your head around as a new user

    there .. i finally said it ... shoot me if you wish ....

  • @discopimp
    indeed, galapagoose is currently employed by monome.

    i'd agree that the search function is pretty bad compared to the old one. makes troubleshooting a lot harder, especially for newcomers. finding anything is a pain now. the initial setup on win/mac has always pretty easy and without problems for me though.

  • zebra: "what if serialialosc itself had a test option?"

    yeah. or, preferably, as a separate command line based program. my suggestion is - it should be very simple and should not even emit sound or anything. text based is okay for me. i'm a console guy. but for the majority of users perhaps a gui version would be more helpful.

    galapagoose: "i have a weird feeling that if people are able to turn knobs / press buttons, and see lights, they might be freaked out when it doesn’t make any sound or send midi anywhere??"

    not true. imo through setup instructions you are setting user expectations. users expections should not be "the monome is for sound and midi". it's a generic device. that's the beauty of it. that's why it's going to live way longer than any launchpad or ableton push controller.

    my suggestion is: describe the absolute basics in the setup page: how to hook up the devices, install drivers and test the communication. other sections should handle sound, midi.

  • @discopimp : sorry to hear you endured a long time of frustrations. sincerely. it's real pain.
    you put galapagoose proposals into a funny angle, but i think you're right though. it's about expectations.
    here is what i expect from monome : 'open source devices of undetermined use' and a protocol of communication. i'm not able to conceive this tool/instrument/apparatus, and i'm not able to build it. i'm glad monome is, because i need this device. i don't expect monome tutorials about max/msp, pd, sc, etc. i don't expect gretch to teach me scales, or set up stomp boxes. i don't expect monome to teach me how to play with apps shared by users either.

    @galapagoose : with this in mind i've bought 2011 64 and arc 2. here is my first experiences. i've plugged the devices and saw blinking lights. great. it's not painful. then i've spent long hours on the forum to understand why i couldn't get it to work like tehn, raja, edison, stretta, daedalus, you, etc. did. days… weeks… meanwhile, i've learned a lot of things about my computer and inter-apps communications. and step by step, i've improved my ability to play in a stable environment.
    what helped me to enjoy this learning experience / process was a good search engine. i think this one can be improved.
    +1 to @jah's proposal : 'provide a super-simple platform independent test application'

  • @discopimp your comments wont make you unpopular...i'm left confused because it sounds like you dont really believe that this has been (until very recently) a two-person operation. we all bought in to this knowing that the community would work together and share ideas/information.

    can the documentation for setup be improved? yeah...this thread's existence is proof that they see a need for user-friendly docs.

    but frankly, if push comes to shove, i'd rather have an instrument that wont fall apart in my hands than a bunch of video tutorials

  • @gli

    oh yeah i have no problem believing it's been a 2 man operation ... makin it even more profitable, so i repeat:

    "for sure the grids have generated enough revenue and profit to provide adequate install and config software and a proper indexed search engine and documentation section for this site"
    i think that 'we, the community' have given enough money, blood, sweat and tears to be rewarded with a bit more professionalism

    if you don't have time to do it yourselves, outsource it, it's going to be better that way anyways, no offense but brian isn't even able to explain why the aleph is such a cool revolutionary instrument, not even to a point where people like peter kirn from create digital understands it (who i believe to be a reasonably intelligent and knowledgable guy in the field of electronic music and unusual instruments), nobody except a few hardcore monome freemasons have even the beginning of a clue what the fuck that thing does and current demos sound samples are rather deterring ...

    it's no secret that experts and scientists are rarely the best at explaining things to beginners and end users, that's why there is a lot of people who make a living writing documentation, manuals and recently doing video tutorials ... don't ask what people want .. listen to peoples problems (which i think have been blatantly obvious for years now) and come up with a proper solution ... then ask again if it doesn't work out

    case in point about the forum: there isn't even a fuckin quote function or any text styling here so i always have to use @whoeverthefuck to talk to people

    as i said somewhere else already, enough with the stupid pseudo minimalism and enough with relying on the wholy 'community' ... IMHO this is just lazyness, stingyness or both and bottom line: BAD DESIGN .. but yeah it's consistently bad design and comes with an attitude .. i'll give you that :)

    btw: i'm not asking for video tutorials about max, and i'm not talking at all about the 'community' of app developpers, i'm just talking about what comes in the box ... but in fact i'm not asking for anything, i'm just relating my and a lot of other peoples frustrating experiences and to be honest i'm not sure why i even bother

  • @discopimp - from what I'm reading, the ball is in your court. You made a bunch of suggestions and galapagoose has spent time reading them over, thinking, and responding.

    Here's just a handful of the questions you could have provided answers to instead of dropping f bombs and whining about having to type @whoeverthefuck in the forum:

    1. can you please describe a ‘plug n play’ installer..?
    2. video is a great idea. do you have any links to videos that are a good example of this?
    3. please help us with specifics of what could be moved / restructured.
    4. can you link to the NI maschine videos?

    Maybe try getting involved in the change you want to see?

  • @discopimp from what i gather, the monome folks enjoy directly interacting with us...they find communal exchange invigorating

    sometimes that includes dialogue with users who need help

    i can understand if you disagree with their approach but it seems like a deliberate choice (rather than laziness)

    trust me, i've been thru the frustration of setup and i think we're in the same boat when it comes to just wanting things to WORK. i'm one of those people who, as you put it, "just wanna drive" not tinker with the hardware or software.

    i, too, agree that a video would be helpful. "outsourcing" is beginning to occur thru some of the work trent + soren are doing (remember the massive serialosc update thread?)

    but i dont think monome will ever be keeping users at arms reach or minimizing one of the central pillars of the company.

    as an example: i recently had trouble getting started with an arc so i emailed monome. brian contacted me directly to help and we found a solution within 24hrs.

  • regarding aleph
    the designers are under no obligation to explain what it does

    those who would like to understand its ablities are free to read about it
    (if you are unimpressed after research or cant be arsed to dig thru the facts...ignore it
    move along and use whatever works for you)

    the project seems to have sprung directly from the performance needs of brian + ezra so, in that respect, aleph fits perfectly into the lineage of other monome gear: flexible tools designed with their own creative efforts in mind

  • sorry, redacting a bit of a rant there! heh

    here is the maschine media. NI produced 2 "overview" videos which are basically ads, conveying very few specifics.

    then they have youtube links to instructional videos produced by *other people*, presumably for various commercial purposes.

    in theory, it seems great to have some video explaining stuff like the aleph, from basics. in practice it is kinda difficult to do, and a lot of the initial reactions are not very motivating.

    anyways this is all sort of off-topic!

    the main points i see are:

    - forum search is not great.

    - need manuals ( i agree, i hate having all docs online... versioning becomes a pain, but at least a downloadable reference to serial/OSC protocol is totally necessary.)

    - simpler and less max-dependent initial test suite (totally agree.)

  • just mentioned aleph as an example of engineers not being good at explaining/selling/teaching, nothing more

    zebra main points are pretty good summary although i think 'not great' is a metaphor for complete disaster and installer is missing .. you know standard stuff: unbox, install software with a couple of clicks, read manual or watch tutorial while installer runs ... plug in and play

    lot of changes @ native instruments .. they have recently removed the vids i was talkin about it seems, probably cause they weren't accurate anymore with v2 since not only the software behaves differently now but also the hardware has changed ... and 2.1 is coming up .. hope they'll bring em back since they were very good tutorial vids ... it was the bald guy doing them who is a great video tutorial maker

    i'm not going to go into more details as those i already explained cause as already stated i don't think it's up to the users to provide a good user experience, i think i made my point several times over and those comments were directed at the owners and employes of the company i bought three and a half grand worth of hardware from ... it's called customer feedback ... so i'm not gonna get into sissy fights with people pickin out random statements from what i said ..

  • well i'm one of those employees, and i'm one of the aleph engineers. and yep, you sure did make your points alright. ;)

    again, the request for a one-click installer has huge holes in it, which we've pointed out. biggest problem is that of course monome can't install max for you, and there is no one application that everyone who buys a monome wants to run. not trying to start a "sissy fight" there, it's a real problem...

    i'm not even sure its resolvable at all as long as the "monome experience" relies on proprietary software components from third parties - and monome is actively trying to move away from that situation - but if you have a specific solution in mind we would love to hear it. for example, you never actually answered trent's question about which components were the most troublesome. (it's ok, i think we can guess actually!)

    i really was curious to know which maschine videos you found appealing/useful, and it's kindof important to realize that they no longer exist on the NI site!

    by the way, i like this synth manual a lot. it describes a complex and flexible device, and is necessarily complex, without being overwhelming. easel was 1974s aleph, in a sense - a "meta-programmable" synthesizer.

    i also post it to support your thesis that a dedicated technical writer can often do a much better job than a project's designer, and that even the smallest of teams should be able to pull it off. in this case, it took a friendly and smart early adopter to step in and help. this is perfectly natural and shouldn't be seen as a ripoff - there are surely better ways to make a living than trying to sell this kind of crazy shit.

  • @emergencyofstate I can picture a plug and play installer. It would be like the sync software for my android smartphone. The install package installs the sync exe, and probably adobe air or similar. In that case, you don't know till you get there, and think "oh no, it wants to slam in a load of resource-gobbling stuff I don't otherwise need". In the case of monome, it's light, benign and up front. To be honest, I'm not sure there would be that much of an advantage, because such a package would have to force installation paths that might not be to everyone's taste (or advantage, if you run a multi boot system). I am happy with the current situation: it leaves me more control of the software ecology on my system, than an automated install package would.

  • i gotta correct myself: just looked and FTDI does allow redistribution with license. so a minimal installer package for mac / win is possible (just the driver and the serialosc bridge.) dunno how helpful that is really, since 3rd party installation of most of the music apps is still a flat-out impossibility.

    as a user, my desire would be to have those low-level bits, and a protocol guide, in one package. the rest of the software ecosystem surrounding monome devices really needs to be navigated by the individual according to their desires.

  • @discopimp beyond this thread, had you ever tried contacting anyone from monome about these gripes?

  • A collection of four or so pdfs - call them white papers, whatever:
    A primer on interfaces, the constraints of laptops for performance and the rationale for grid controllers. Perhaps some comment on the nature of digital music and interaction, and why grid is good. Note also the limitations - is it a great interface for physical gesture?
    Individual primers or overviews of how a monome fits in with Max/Max for live (with a simple description of what Max is), one for PD, one for SuperCollider (maybe?), one for Cubase, you get the picture. Maybe some consideration of how this works with different compositional and performance approaches.

    I'm not volunteering to write them, and I don't think they should be written until there's a strategy sketched out with monome, to establish some kind of road map. For example, I'd see such a set of documents as an expectation management tool, but that may be anathema to everyone else.

    Why do I think this might be a good idea? Firstly, the academic-style papers that come out for max-related activity have been very helpful to me, and spurred me on to be adventurous., Jean-François)
    Secondly, what a great opportunity to extend the monome aesthetic! I'm all for elegant documents.

    edit: - maybe not white paper. Maybe manifesto.

  • yeah the monome document(s) as you describe them would be a really great project! I was pondering just such a thing yesterday. I'm a technical writer, wish I had the time for such a cool project! i could give some time i guess. when the baby goes to sleep maybe :)

    that said, I'm not sure the topics you describe would go into a manual, or at least a manual that i would write :)

    white paper/manual/manifesto - all completely different things.

    the Aalto manual is great:

    must check out that Allen strange easel doc. thanks zebra.

  • @ootini you're right - they are different kinds of document. It strikes me that an equivalent to Bauhaus/futurist/surrealist manifesto could be a more fitting way of presenting things than a manual. More why to than how to.

  • except that a manual is what is being called for here, not a manifesto. maybe.

    'how to' doesn't necessarily have to preclude the 'why' though. which makes it a potentially very cool project for someone.

  • the aalto manual IS great @oootini

    looking for some videos that may serve as a reference

  • the kaivo 'manual' is really neat!!! a mega enjoyable reading thus far.

  • it's emotional business, but the replies are much appreciated! all these details allow improvements to be based on a more empirical approach, rather than 'it looks like everyone has this problem - let's focus on that'.

    if there's anyone else who wants to share their personal experience, whether positive or negative, we'll take that on board too. i know it might seem overdue, but 'better late than never' eh?!

  • Interesting. I remember when I started I was the epitome of noob. I wasn't familar with MIDI, Max, anything really.

    I second the idea of perhaps just providing motivation for things. I remember it took me 2-3 hours to get things up and running but it was just blinky lights, so the next day I started looking for apps to try, finally got polygome to feed MIDI to Grageband after 2 hours. It felt good after that, but I was about to give up several times along the line.

    So maybe just have only one guide of setup instructions to avoid confusion and provide in there a patch with pre-built sounds so they don't have to do MIDI routing or find samples or anything, that way if they get all the drivers working, an app presents themselves with absolutely no confusion and just good sounds.

  • Thinking back to my noobness, I wish this video had been around:

    I think video can go a LONG way with some of the high level conceptual things you need to get your head around like MIDI/OSC messages, hell just plain data messages. How to think about what is sending OUT, what is receiving IN, etc.

  • i am happy to answer this question, and tell about my initial (and continued) user experience. it feels good to be able to do something concrete in return to help out the community which has given me so much over the past 7 years. here are a few notes i wrote down a few days ago when this thread first popped up. since then, it seems a lot of the ideas brought up so far are similar to the ones i was thinking about as well.

    for a quick read, i want to start with a summary of concrete things which might improve the setup experience for first time users, or at least issues that came up upon reflection of my personal experience. then, keep on reading for a longer explanation of these actions and perhaps more context of the issues involved….

    concrete actions to possibly take:

    - simple demo vids demonstrating documented steps and displaying basic functionality (of each app, setup step, and/or hardware maintenance). to this end i can certainly donate my time to help make this happen according to my ability outlined later on.

    - suggested reading lists for the main subjects that you might encounter when working with a monome and its extended community. again, please see below for an outline of what exactly i mean by this and my ability to help make it happen.

    - tech support in the form of either "officially" paid employees with a charge to the customer, or then a more organized community approach with a (curated?) list of willing and knowledgable people who are available in some for for a charge. in general people from all the subcultures i have encountered are basically allergic to spending money on things like this, in the fear that greed will destroy any semblance of a working community. below i try to argue against that belief, and show how something like this might actually work in a positive way.

    - the further refinement and establishment of more clear and concrete habits inside the community regarding things such as documentation, formatting, and sustainability (backwards compatibility?) in relation to both hardware and software issues, also in consideration of third party products and perhaps a closer look to see what habits, if any, can be promoted within our group to better navigate into the future. this is the thing i know least about in terms of technical and/or practical detail, but i take this thread here on the forum to be part of this overall concept as is several other initiatives that recently started inside monome as a company.

    and now on to try and explain these ideas clearly and productively… which i think takes a lot from the context of my personal user experience. before i get to that i just want to say that what some people have been calling minimalism in the design of anything other than the hardware devices themselves is probably more accurately referred to as the extreme dedication monome has to the openness of its devices in terms of the end user's goals. sure, the website graphic design is minimalist or whatever with no big flashing banners or ads or bright colors, but for sure that is also not what people mean either. this perceived lack of information or minimalist philosophy with documentation is more of a hesitation to not assume too much, to already steer the user down one road rather than another before they have even started. and, in my eyes at least, the minimalist design of the hardware was also born out of the desire to keep the possibilities open to as much as possible. it looks pretty, its a personal philosophy, and definitely a design choice which could have been different otherwise, but as far as i can tell the main reason there aren't things such as labels (on buttons) or even visible logos is because monome really does want you to be able to do whatever you can dream up. as others have already brought up here, that is one of major dilemmas to deal with- how to keep everything as open as possible, as far as possible into the process and yet at the same time provide relevant support once user choices (and habits) have been made.

    also just want to point out, minimalism doesn't mean lack of information or design considerations erasing or preventing important and useful features from existing… minimalism means the least amount of design/work necessary! so if it was necessary that monome grids had RGB led's (in the opinion of the company's designers), then the grids would for sure have them. clearly RGB led's haven't been deemed necessary considering manufacturing processes, company structure, the growth of the current community, or whatever other million things they have to consider along with their own vision for their product. and as far as i can tell the same goes for how they run their website, forum, and other public and private company relations.

    again, its slightly a relief to be able to share these thoughts in the hopes that they might do some good- i don't look upon monome as preying on the community, for the community to do their work for them. rather, monome has the task of keeping the community alive, and when they are doing that job perfectly their influence and involvement will not be noticed at all- things will just be swinging along and their presence will be invisible (and that's how i've mostly seen things be around here). its always impossible to tell for sure one way or another with this internet community stuff, but isn't there a reason why monome has managed to nuture a community from its own website? teenage engineering has a very active community of users who have created their own independent forum since that company chose to not have one yet from their end. and so while monome clearly wishes to engage with its users in a very direct, welcoming, and public way, i don't expect that i have as a basic right access to this community when i buy a product from them. i could have found the product through the community, and the community can be a driving force to access the hardware, but as a sense of entitlement, that's a whole different expectation. and once i am in the community, any contribution i make certainly has no reflection upon the transaction i made with them from when i bought my device except as set out in the terms of that sale. i don't expect, as part of the sale of a device, that monome is responsible to fix any problems i have that are not physically related to the hardware not performing as advertised (manufacturing defects beyond normal wear and tear or accidental damage, etc.) and also monome needs to provide a protocol to connect the hardware to my computer (since they say they will do that… brian even ships usb cables with the devices, a physical symbol of him providing the software driver too).

  • now, when third party software (os updates) and hardware changes, i don't expect as a continuation of my purchase of the hardware that monome will automatically, immediately, and without pay maintain all my current compatibility and functionality. i only expect them to keep providing a relevant connection software. beyond that it is up to me how i want to deal with the situation. and this is precisely when i'm forever in debt to the community and endlessly grateful for monome to provide and care for such a community. perhaps this is what @zebra was pointing out earlier in this thread, trying to remind us all of what to rationally expect out of the company on the most basic level. all of this being said, i don't think monome just wants to sell a device, and post a connection software, and then not get involved with anything after that. perhaps in the earlier days the average monome user was a bit more DIY in terms of programming for the device… i remember a stretch of a few months years ago where it seemed a new patch was posted almost every day! this stream of new apps has calmed down considerably, but clearly devices keep getting sold, and the number of users is growing. but they are also growing in a world now full of the grid culture which monome itself kickstarted. what i mean is, perhaps monome started out with intentions heading in one direction, and have now ended up in a different place. not worse. not better. but just different. and again i see threads like this one as a positive sign, of them taking note of where they (and we) are now so as to make the best decisions of how to go forward. for sure the first steps of the company produced users who had a different need and relationship to the community than there is now. and the company i'm guessing has changed and is changing along with it.

    maybe monome started out as a tool for digital artists who wanted to fill in the blank slate brian provided. but along the way a community grew in a certain direction related to music. now when people enter into the community you get musicians or people interested in music such as myself, people who were not invited through the computer code route. this is also part of the fundamental problem or dilemma of a first time user. they go in with the expectation that they are going to make music, but before they can do that they have to learn just a bit about how their current tools work, such as their computer hardware and software which is already running on it. and again, monome can stress that it is a blank slate to do whatever with, but a large part of its public persona and also the related knock offs coming after monome came out, position monome as a music making tool and in comparison to other music making tools the process to use monome is slightly different. you can of course say that's not monome's problem. and sure technically its not, but you can't escape the culture we are all surrounded by. so while monome isn't obligated to respond to this on a basic level, on the practical level it does have to respond to this.

    the guy who first told me about monome said i shouldn't get one because i would never figure out how to get it hooked up to my computer. he was a professional musician and computer programmer. i was exactly the opposite of both of those things, but setting up a 40h was absolutely no problem for me at the time with the instructions and software available then. more recently i have had different experiences setting up serialosc devices, and the aleph. i liked monomeserial in the sense that it was visible… it didn't run in the background, it was something i had to open and so when it wasn't open, i knew something was wrong! i also had a very concrete starting point of where to start troubleshooting. as well monomeserial had very clear places of where to change prefixes, cable orientation, row offsets, and more. serialosc runs in the background… and for sure there are ways to check that its running, when its running, how its running, and there are ways to deal with cable orientation, row offsets, etc. but my knowledge of computers and music and programming all stems directly from my use of monomes over the years. so i had a personal learning curve when serialosc came around. i still don't know how to change prefixes if they aren't automatically changed by the app. i have no idea now how to change cable orientation or row offsets or whatever else i used to do in monomeserial. at the same time, i guess i haven't needed to do these things bad enough or i would have learned by now. after a rough start on serialosc (i'm guessing because i was installing it while new versions were still coming out, which might have broken earlier versions or who knows), serialosc seems to be working on my main machine, at least enough to interact with the monome hardware i own which requires serialosc.

    serialosc broke my live set which runs on monomeserial. at the same time, my live set can still be performed on monomeserial just fine. the only limitations are that i can't integrate newer monome hardware or apps into that particular work. that results in having to carry around extra hardware. but the set is built upon free apps from people who generously shared them. i don't expect that it would continue to work forever, but of course the fantasy is that all subsequent releases of software and new hardware design would continue to be compatible. but its like any technology- sometimes it breaks with a new generation. you have to leave something behind to move forward. even with new serialosc'd versions of the apps involved, migrating it all over from monomeserial, there's just no way it will work- least of all because it relied upon some music programs which my new apple laptop hardware will not run anymore (at least with my current level of knowledge and/or desire to install multiple operating systems and partitions, etc.). there's always this desire to keep everything and never throw anything away, both creatively and literally in terms of hardware. but i'm sure that in a couple of years, once the aleph has taken over my life, i won't miss the monomeserial days, and i can part with the extra hardware… after all, it is still valuable because serialosc is backwards compatible at least!!

  • thinking about this transition from monomeserial to serialosc led me to think about one of the concrete steps listed above which might help new users. since the process of using a monome has led me to research things like terminal (is that line command?) on my laptop, midi, osc, audio routing on my machine, max/msp, chuck, pd, github pulls and a million other things along the way, i realized that if there had been some sort of list from the start, maybe a list of related reading or something, then i could have gotten up to speed in a matter of weeks if not months instead of years. again, not that its needed, but it would have been a great help looking back. something like a starter pack of issues that are frequently encountered by the type of monome user to which a guide like this would be helpful. so it is actually targeted to a specific group of monome users, and not totally open ended trying to cover all the bases for everyone. or then there's 3 levels or 3 different guides or something. for example, in the noob one there's suggestions of subjects to learn about and perhaps even pointers of where to start looking in regards to basic midi, how audio is routed in different operating systems, max/msp, pd, supercollider, chuck, but then also other mundane things precisely related to the community support system such as how to use the forum, how to read and format entries in a wiki, where to go for live chats, what a github is and how to interact with it in a basic way, so kind of also an introduction to the infrastructure that exists to help users as they get more deeply involved? as well the starter pack could point to artists who use the monome hardware and software in very divergent ways, maybe even point out some resources for sustainable manufacturing, open source hardware ideas, or anything else which makes the company unique perhaps. i think many in this thread have already made similar suggestions for a collection of information such as this.

    even after working with monome devices and then jumping very deeply into various music hardware over the years, making and performing many live sets, i still don't know things like- using different midi channels with monome apps, using ableton live with monome apps, how to get live input into mlr, what exactly a sound card for a computer is, and on and on. i guess i'm saying i feel like i have some very specific knowledge in some areas but i'm lacking some overall basics. certainly it isn't the company's job to provide me with this information, but i think what would have helped me at the least is if someone would have positioned monome in a certain context in relation to all these different things. just a simple line somewhere by someone at the start of my journey saying something like "hey, you should really find out what sound cards are, research the different kinds and their functions because frequently new monome users with little computer experience end up getting involved in projects where a sound card could really help." and again, i understand the challenge of thinking you have to anticipate all the possible uses for the device and being afraid of excluding someone in this type of support. but those users who are going to do more advanced things from the start will already have an appropriate context from which to start their experience. its not monome's responsibility to provide starter courses for an overview of all of electronic music production, video design, and whatever else is deemed fit to be included in a starter's guide… but as a community, some sort of frame work or context for where monome might fit into all these places, just as simple starting point would be of great value. i encounter all the time the balance between trying to inspire and just blatantly telling someone what to do which leaves them depending entirely on you with each further step. but a first example in a few different key directions can get them started down the road and the community is then there to keep nurturing them along as they try to walk on their own. i am willing to donate my time in helping to compile, organize, and/or write some sort of beginner's guide or similar idea as proposed and deemed worthy in this thread.

    when setting up my aleph these past few weeks, i've encountered a problem that has also troubled me in the past with many other things, but also including monome grids and arcs- its not having anything to compare my experience to so i would know where to start troubleshooting on my own. no idea what the desired behavior is supposed to be, so i can't even tell if its already working as it should, let alone if its broken or has then various other degrees of functionality missing. this made me think that a simple solution is just very simple, and short videos collected somewhere showing the most basic behavior of things. the point would not be to try and document every little feature, or every single twist or variation on an app. rather, just a clean shot of a computer screen or the hardware when needed, and perhaps even just following along any instructions that are already published. to that end i volunteer my services- for example to come and film soren for one week, just going down the list of apps on the document section of the website one by one and filming material to make 1 minute long videos for each app demonstrating each apps most basic functions. i don't have the technical know how from the monome side or i could just make these films myself. i can bring a camera, and i have basic editing skills, and i can get them online and linked to where they need to be. a concrete example of how this might help is from when i was setting up my aleph now- the instructions said to download the .zip, unzip the file, and put that onto a sd card for the aleph. my problem was that i didn't have the sd card which was send with the unit and so i never saw the original file structure on the card- whenever i would unzip the file from the website i would end up with a master folder… with the 3 subfolders inside. but i didn't know that the 3 subfolders needed to be copied onto the card separately. just a stupid little confusion on my part, but a very short little demo video of things as seemingly simple and mundane as following those instructions would have speeded up the process by a few weeks of moving forward with the unit. even now i'm still confused as to what i've been doing wrong in compiling the latest version of bees from the github… it seems when i do it myself the result requires a reflash of the unit each time its powered off! i'm sure if i could see a little video of someone doing this process, i must also be misinterpreting another word in the process somehow. videos could even be as simple as this one, showing flin:

  • this might be a hard thing to talk about but i like paying people money for things i can't do. i like paying monome to build hardware for me so i don't have to. therefore, i also like paying people to help me out with computer programming problems so i don't have to learn computer programming. i think this is normally seen as a "lazy" approach but i couldn't see it as being farther from the truth. it all depends on what your ultimate goal is. usually my goal involves getting a certain behavior out of a software system so i can make some music or video or produce an end result. in these moments my goal is not to learn how to write code in C. or even how to edit patches in max/msp for that matter. i devote my life to other skills that people pay me to access. i see that as my job and the most efficient way to move forward for me is to trade my skills for money, which i can then trade for others to help me out with things i can't do. when i am sick i go to the doctor. i don't go to medical school. and i get it that money is a finite resource so i am limited in my desires to do things i can't do by how much money i have. but the hours and days and weeks i have been incredibly inefficient in my original goals hurts my overall productivity. you could point out that i have been learning all that time, and indeed that is true. in fact for sure that helps me in the future, any experience i get i try to turn it into a positive lesson to remember later on. but that was not my original goal. if i could pay someone to program my laptop and setup right now, to add all the features i would like, to get it working to a level i can deal with using my current level of intelligence, and if i could afford their fee, i would pay them in a heartbeat!

    and this to me gets to the idea of paid tech support in some manner. while i can't thank everyone enough for all their years of helping me out for free on the forum… that's just it!! i can't thank them enough. i rely on them. i need them. i need them more than they need me. so i call upon their good will, their charity, their kindness… and of course they get something out of being a member of the community, and its their choice to be involved or not so i don't feel guilty to ask them for help. but then i also rely upon their schedule, their desires, their level of skills or lack of them to do what i want. the forum is a hobby. its not a professional service (i'm not saying the forum should be either). but the forum isn't even a place to find a professional service. every few months someone desperately posts, looking to commission someone who can code something related to monomes. i don't think anyone has ever found someone to take them up on their offer, to get hired. i can't remember on the monome boards, but in other communities where things like this pop up, the members are afraid that if someone accepts a commission, all of a sudden everyone will get greedy and all good will disappears under a flood of high priced offers to help whenever someone asks. first of all i have to say that in these other communities it didn't play out like that at all. what happened is there appeared another level of user interaction, sometimes people would hire each other for specific jobs. it didn't cannibalize the community, it just added another layer on top. as well the monome community has bred a culture of sharing code and patches for free. i also don't see how this would be threatened, or even weakened. the supportive vibe and general friendliness can still be there even if sometimes people have to get paid. i see a few donation pages starting to pop up here and there, like mark eats. he set his system up to donate to charity and that's amazing! i hired and paid a guy to write the code on my quantum patch which i then put online for anyone to download as they wished. the code in quantum was built upon shareware, and in paying the code to modify the code he wasn't stealing the code or profiting off it or making it exclusive. he was doing some work which i couldn't do myself and that's the part i paid him for.

    perhaps it could work in a couple of different ways. i'm guessing its a crazy logistical nightmare to set this up and deal with it on an "official" level. but have soren available for x number of hours per week for paid tech support. set a price and users can buy x amount of this time for x amount of money. of course there is no guarantee that soren can fix your problem, but at least its a codified place to go at a specific time with a specific interaction. soren is paid by the user for his time, a salary just as any other job. i'm guessing there would be a bad economy of scale to this, let alone trying to define how it work exactly. but if soren was on call, i'd throw him some money to help me out every few weeks!!

    but maybe the other way it could work is to just have a (curated?) list of people available for hire somewhere on the site? in the ideal world, word would spread through the coding community that there's a list up on a dedicated spot on the monome website where coders can place their contact details (along with price structure, and specific skill sets?), and so coders would be eager to sign up for some potential extra income. again, a concrete example of how this might be useful is that i have another patch which i designed years ago that i'm dying to have. but have been unable to commission the patch from anyone. i've had 3 offers to do it for free. but in these past 3 years it just doesn't get done. this is getting pretty far outside the scope of helping a new user get up and running, but again, with basic problem solving also available for a fee, and looking back at my time spent wrestling technical issues, i would have died to have a resource or service like this!

    a final obsersvation is that the performance and artistic videos from tehn and stretta over the years have created the entire empire. these glimpses at what can be achieved through interacting with these devices and community is nothing short of magic. i know its what got me hooked. to see these iconic videos was to see behind the curtain, to have a brief epiphany of what might be possible and why this company exists as it does. these videos kept me going when i was having technical troubles because i knew what could happen if i just kept going. this idea of inspiration is not trivial when talking about the first time user. so one very easy way to help the first time user even more is to make more achingly beautiful videos, of things we can only dream about making one day. and these images will get us through our roughest hours!

    videos like these:

    (so do i win the world's record from raja for longest post ever!?!?)

  • "(so do i win the world's record from raja for longest post ever!?!?)"

    yes, yes you do :)
    (next time, though, at least drop some comedic self-deprecating satire or somethin'... some of that was just plain boring... oh wait... i forgot: you weren't writing it for me :D)