borfo

Programmer
  • Content count

    298
  • Joined

  • Last visited

Everything posted by borfo

  1. "Hey you idiot, you forgot to flash the goddam firmware." Duh.  Solved.  I had assumed it was preflashed by smashtv, but I guess the PICs just had MIOS, not the SID app.  Seems to be working now!
  2. Change MIDI pair numbering?

    You are not blind.  Instead, I am an idiot and linked the wrong page as someone already pointed out.   But now that I see the pictures of your box it looks like everything is as it should be - if the numbering seems weird to you now it probably won't take long to get used to it.  Or if you wanted to, you could swap the two I/O boards, but then the back panel labelling would be wrong and you say you don't want to open the box... Fancy work on the build too.
  3. The answer to this doesn't seem to be obvious in the docs, but given how flexible MIOS is, I figured I'd ask. I'd like to have a few buttons with LED indicators (maybe 8?), as well as an encoder or two attached to my sequencer frontpanel that always serve as a typical midi controller - like, the buttons and encoder would send CCs to another device via midi, and the buttons would have LEDs that could be lit by the connected device as indicators.  I could build an arduino thing for this, or an NG.  But since my needs here are pretty modest, and my SEQ is right there and already connected to everything I'd ever need to control, I'm wondering if the SEQ could support having a few extra buttons/leds/encoders attached that would function as a dedicated midi controller...  Not really a mixer map type thing, sort of a minimal NG, but I wouldn't need any banking or anything - these buttons could always send/respond to the same CC, out the same port, no matter what the SEQ was doing. Would this be possible?  How?
  4. Change MIDI pair numbering?

    If you look at the jumper description for J11e on the MIDI IO page (http://www.ucapps.de/index.html?page=mbhp_iic_midi.html), you'll see that the midi inputs are directly pinned out from the core board.  So, most likely your cable (or whatever you have running off of J11e to connect your IOs) probably has a few mixed up pins.  You should be able to just rearrange the pins and fix your problem.
  5. Have you been following that "Let's invent a new frontpanel thread?  I'm liking the fact that the rows will all have 16 buttons - makes a lot more sense...   And given how well the launchpad minis line up with the LCD columns, I'm tempted to make a tiny SEQ frontpanel that only has the encoder row, the datawheel, and maybe a handful of other convenience buttons.  If you could put MIDI assignments in the SEQHW_V4 file, instead of just shift register numbers, or if every parameter that could be controlled by a frontpanel button or encoder was coded to a MIDI CC/SYSEX/NRPN/etc. address (OSC would work too...) then the launchpads could be both the BLM and 16 rows of 16 SEQ buttons.  The launchpad buttons and LEDs are way nicer than tact switches, too. It would be easy to tie all the parameters to MIDI, but if I'm remembering right, the reason they're not is because of low memory on the LPC17 Cores.  Once he makes the move to the STM32 V4+, this should be easy to do.  Even if they're not all accessible by midi yet, there are quite a few MIDI controls.  Certainly enough to make SOME fun new BLM modes anyway, even if all the frontpanel functionality can't be duplicated yet.  
  6. MIDIbox SEQ new frontpanel idea

    I'm in the process of designing myself my perfect self-contained MIDI jam case, and I've been planning to make a new SEQ anyway.  I've already got a bunch of these panel switches and they seem pretty ok...  I think I may as well try a panel mount job with a few customizations.  (I had actually also settled on using rows of 8 instead of the Wilba design.) Great timing that this new design is finalized though - wouldn't want to build a new seq only to find that everyone's using something totally different now. Anyway, great work on the design.  Looks great, and the modular design will be totally useful.  Same with the consistend 8 button grids.  Everything's 8 in Midi, and in a lot of music.  Having that consistency in the button rows will naturally lead the interface to become more useful and intuitive, I think.  
  7. MIDIbox SEQ new frontpanel idea

    You're probably right re: just using DIO and DIN's... I figure with the panel mount switches, I'll just buy a bunch of extras and it'll be pretty easy to replace them if they fail.  And I figured I'd use LEDs in addition to the buttons instead of bicolor leds.  But $1 per switch on your design is a good price.  I was expecting a price along the lines of those marquardt switches that people were using for a while.  I've had good luck with the cheap chinese stuff, but at $1/switch, I may just build your board - at least for the button part. I didn't realize you were at the board-ordering stage already - I haven't been here for a while, still catching up on new developments.  When do you expect to have boards to sell?
  8. MIDIbox SEQ new frontpanel idea

    Oops...  They make both momentary and latching versions.  I bought momentaries - I just wasn't paying attention when I searched for that link.
  9. MIDIbox SEQ new frontpanel idea

    Or, alternately I guess, it would be pretty easy to make a second variety of frontpanel PCB that just does the same multiplexing, but pins out all the frontpanel LEDs, buttons and encoders instead of providing pads for PCB mount controls...  That would make these PCBs very small and affordable. ...that's kind of what a DIO module is, I suppose.  But a pinned out PCB that was multiplexed, marked and designed to be used with the same MBSEQ_HW.V4 file as the commonly used frontpanel PCB would be handy.   Edit:  I just found this great pinning diagram of wilba's panel that maps it to a DIO Matrix and a DINx4 (http://www.ucapps.de/midibox_seq/mbseq_v4_dio_wilba_layout.pdf), which goes a long way towards what I'm suggesting here...  A little PCB that piggybacks on the headers on the DIO_MATRIX, holds the diodes, and pins out and labels the button and led matrix coordinates would be really handy though.  Maybe I'll design one...  Hm.
  10. MIDIbox SEQ new frontpanel idea

    A suggestion for these new panels:  Could you add holes for 2.54mm headers to the encoder, button and led pads so that builders could choose to pin out to panel-mounted controls and indicators instead of using the recommended buttons?  This would give builders a lot of options, but would still be way less hassle and way easier to troubleshoot/assemble/etc. than wiring up a frontpanel straight to DIO/DIN/DOUT modules. I've recently found these super cheap 16mm illuminated panel mount buttons on aliexpress - https://www.aliexpress.com/item/ON-OFF-illuminated-round-Latching-Push-Switch-4pin-1A-250V-3A-125VAC-Green-50PCS/514238730.html (Oops - linked to latching buttons - they also make momentaries in the same style.) They're $0.60USD each.  Pretty affordable.  I ordered some, and they're pretty nice actually, and come in quite a few colors.  I was considering building a new SEQ with these buttons panel mounted and wired to DIO modules, but thinking about the rats nest of wires that would be required is a bit scary.  If this new PCB allowed pinning out the controls to headers, that would make a project like the one I'm thinking of very doable.
  11. I realize that it's not a particularly detailed license - I'm actually an intellectual property lawyer.  But TK's general awesomeness more than makes up for any failings he may have in the intellectual property license drafting department.  Haha.  "Personal noncommercial" is a license though, it's just a bit vague. Seriously though, I love TK's attitude to IP in the work he's done, think he's built an amazing system here, and think he should own all the midibox related code so that if he ever decides to move to a different licensing scheme, he won't have ownership issues.  So this code is his to do with as he likes.  Do you want to do anything with this code that "personal, noncommercial" wouldn't work for?  I probably wouldn't have issues with that, but I already assigned copyright to TK, so he's the one who'd have to grant any licenses. Maybe he'd grant you a Death and Repudiation License if you asked nicely...  Haha.
  12. Hi all - and particularly TK since you know this stuff better than anyone: I'm writing a headless BLM scalar implementation in Python (using Mido - http://mido.readthedocs.io/en/latest/index.html) for 1-4 Novation Launchpads.  I wanted to write something that doesn't require the user to run a windowing system like the Juce app does - something that would be easy to run on a headless Raspberry PI.  I'm pretty much finished with it - I'll post it in here when I'm done. I have a few questions though - things that weren't totally clear to me from the BLM protocol docs, etc. Can I expect the device_id of all MB Seq's to be 0? If not, can I send a message to the seq to request its device_id?  How? (my sc ript currently sends a series of pings where the device ID ranges from 0 to 127  out all 4 discovered MB SEQ ports - when it receives a ping response, the script automatically learns the port number and device ID.  Is there an easier way to get the ID??  (NOTE to future BLM developers: the Seq will not respond if you send it the wrong device ID) ) Other than the BLM Protocol document and the CC and Remote MIDI implementation documents at trunk/apps/sequencers/midibox_seq_v4/doc/, are there any other SEQ V4 MIDI implementation documents anywhere?  Or are those documents a complete list of the control-type MIDI messages that the seq will send and respond to? Re: the sysex layout message: F0 00 00 7E 4E <device-id> 01 <num-rows> <num-columns> <num-colours> <num-extra-rows> <num-extra-columns> <num-extra-buttons> F7 Can you explain these a bit?  Numrows and num columns are self explanatory - I assume they should be 16 or 8 for a launchpad BLM, depending on how many Lpads you have. How many colours should I say I have?  Two?  What is the effect of claiming more colours than that?  Will the BLM use more than two colours? What values should I use for <num-extra-rows> <num-extra-columns> and <num-extra-buttons> -- should these be [1, 2, 0]  on a 2 launchpad configuration, and [2,2,0] on a 4 launchpad configuration?  ...and [1, 1, and 0] on a 1 launchpad configuration? Could you explain what num-extra-buttons does, and what extra buttons are available?  Is there any additional functionality I could enable by mapping these extra buttons to the bottom row of round launchpad buttons on a 4x4 layout?  
  13. Some things I learned while writing my pyBLM script: SEQ won't respond to layout or ping sysex messages unless the device_id being sent by the client script matches the device_id of the SEQ The BLM client (ie: the pyBLM script) is just a dumb translator.  All of the real functionality is handled on the SEQ.  The only thing the BLM client has to do is send layout information to the SEQ, translate MIDI messages in BLM protocol format coming from the SEQ into messages the button/LED matrix you're using will understand to light up indicator LEDs, and translate BLM button presses into the SEQ's BLM Protocol format.  It's actually pretty trivial to write a BLM client once you understand what's happening. It appears that the SEQ only uses the column transfer format from the BLM Midi Protocol docs to send data to the BLM, and single-access and row transfer formats are never used.  TK, can you confirm this?   There is some info missing from the BLM SCALAR MIDI Protocol documentation (http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fblm_scalar%2FREADME.txt) Specifically, how to address the second extra column used by the novation launchpad scalar setup.  This should be added to the docs: Sent button events: +---------------------------------------+-----------------------------------+ | BLM16x16 Buttons | 9<row> <column> <button-state> | | Extra column buttons | 9<row> <40+column> <button-state> | | SECOND Extra column buttons | 9<row> <50+column> <button-state> | | Extra row buttons | 90 <60+column> <button-state> | | Additional extra buttons (e.g. Shift) | 9F <60+function> <button-state> | +---------------------------------------+-----------------------------------+ ... SECOND Extra Column optimized LED pattern transfer (prefered usage): NOTE: in distance to single LED access, we always sent over the same channel! +--------------------------------------------+-----------------+ | row LEDs 0..6, green colour, 8th LED off | B0 50 <pattern> | | row LEDs 0..6, green colour, 8th LED on | B0 51 <pattern> | | row LEDs 8..14, green colour, 16th LED off | B0 52 <pattern> | | row LEDs 8..14, green colour, 16th LED on | B0 53 <pattern> | +--------------------------------------------+-----------------+ | row LEDs 0..6, red colour, 8th LED off | B0 58 <pattern> | | row LEDs 0..6, red colour, 8th LED on | B0 59 <pattern> | | row LEDs 8..14, red colour, 16th LED off | B0 5A <pattern> | | row LEDs 8..14, red colour, 16th LED on | B0 5B <pattern> | +--------------------------------------------+-----------------+          
  14. I would start it headless (ie: don't start X), and autorun this script on boot.  Python3 would have to be installed - I think it is by default these days - as would Mido (pip install mido) and python-rtmidi (pip install python-rtmidi).
  15. I was planning on setting up something like this - what you describe would be pretty easy to implement.  The client side of the BLM (eg: this app or the Juce app) is really just a dumb translator at heart - it just translates midi messages incoming from the SEQ into LP led-illumination messages, and MIDI-encodes button presses on the LPs in a way that the SEQ can understand.  All of the important processing is happening in the SEQ. The BLM does make provision for up to 6 "extra buttons", but I'm not sure how these work.  It would be easier and probably better to just configure the extra row on the client-side to send arbitrary MIDI messages on the Ext. Ctrl channel, and not try to use the BLM protocol for these messages.  You could do this yourself pretty easily if you know any python.  Look at the callback for the Pad object, and the Pad[#].buttonmap object. ...I had also thought that I might want to use the extra row of buttons to add some "smart" functionality to the currently "dumb translator" BLM client - add extra modes that I personally would like to have but that TK may not find useful enough to add to the main SEQ program on the server side, or functionality that would be too cumbersome for the Midibox Core. It would also be very easy to add support for other midi devices to pyBLM - eg: maybe you have a korg NanoKontrol or two that you would like to use to control your SEQ in some way - a user with some knowledge of python could add support for one or more other devices that they own by adding a translator class and callback to the script separate from the BLM protocol stuff.  I have a couple of controllers I may add to my own setup...  I have some midi implementation questions for TK before I start with that though.  In theory, it would be pretty easy to write a python script that communicates with a bare stm32f4 or lpc17 core to allow full external MIDI controller operation of a SEQ V4 with a minimal frontpanel, or even without building a frontpanel at all.  But I don't think all the required parameters are available via midi right now.
  16. I figured I'd post this somewhere just in case it helps someone troubleshoot in the future.  I built my SEQ V4 years ago.  It always had an ongoing very minor issue with its rotary encoders - for example, if I turned them in an incrementing direction, maybe once every 10 ticks or so, the encoder would jump back a few increments...  Like, if I was increasing velocity it would go 100-101-102-103-104-102-103-104-105-106-...  A really minor issue - not a big interference with usability - but annoying. Over the years I tried to fix it and could never figure it out - I assumed it was an issue with the encoder types that were supported by MIOS - I played with the various DETENTED2, DETENTED3, etc. encoder type settings in my MBSEQ_HW.V4 file, but couldn't get the glitch to go away completely. Eventually I just gave up and figured that if this is the only real minor annoyance that I had to deal with, that's pretty great for a free and open source device.  But I should have known that much like everything else MIDIbox, TK is a goddam genius and doesn't really screw much up, so there's probably a solution to any problem you might have, even if it's very hard or impossible to find in the documentation. I recently added CV/Gates to my SEQ with AOUT_NG/DOUT modules.  While working on that, I noticed a reference in the docs for those modules that there is a limit to the length of certain cables joining the various modules to the Core - the docs said that if you use cables longer than 20cm to join the AOUT_NG/DOUT modules to your Core, you may have issues with the CV/Gate functions, and it might also result in glitchy readings on digital module components elsewhere in your SEQ (this is why the LINE DRIVER module exists).  Shortening my AOUT/DOUT CV cables to under 20cm fixed an issue I was having while setting up the CV/Gates. Then it occurred to me that maybe my encoder problem might be due to slightly long cables as well.  Mine weren't ridiculously long, but some were probably about 30cm.  But I figured it was worth a shot, and I remade all of my cables.  I made them as short as they could be while still reaching the Core jumpers.  This fixed my encoder problem completely. Anyway, maybe this will help someone else in the future who's searching the forums for solutions to glitchy encoders - I didn't see any mention of cable length when I was trying to troubleshoot this myself until I noticed mention of length limits in the CV docs.
  17. I got a little further in my script, and now that I'm seeing the live incoming data from the BLM, I've got a few more questions: Looks like pretty much everything I'm getting from my SEQ relating to the main 16x16 grid is this type of message - updating each column one at a time: BLM16x16 optimized LED pattern transfer with 90° rotated view (rows and columns swapped, LSB starts at top left edge!) +--------------------------------------------+------------------------+ | row LEDs 0..6, green colour, 8th LED off | B<column> 18 <pattern> | | row LEDs 0..6, green colour, 8th LED on | B<column> 19 <pattern> | | row LEDs 8..14, green colour, 16th LED off | B<column> 1A <pattern> | | row LEDs 8..14, green colour, 16th LED on | B<column> 1B <pattern> | +--------------------------------------------+------------------------+ | row LEDs 0..6, red colour, 9th LED off | B<column> 28 <pattern> | | row LEDs 0..6, red colour, 9th LED on | B<column> 29 <pattern> | | row LEDs 8..14, red colour, 16th LED off | B<column> 2A <pattern> | | row LEDs 8..14, red colour, 16th LED on | B<column> 2B <pattern> | +--------------------------------------------+------------------------+ I haven;t seen any of the row-type pattern transfer messages, or the single-access messages.  Does the SEQ use any of the other transfer approaches for the main 16x16 area?  Or does it always use the column transfer messages? _____________________________ For the "extra column buttons" - the 2x1 and 2x2 launchpad BLMs have two extra columns - looking at the single access transfer: Extra column buttons | 9<row> <40+column> <button-state> Would I be right to assume that if note = 0x40, that means the first extra column, and 0x41 would mean the second extra column? I also noticed some MIDI messages from the BLM that follow the extra column transfer format, but which are not documented in the BLM protocol document.  But where the first extra column messages came in as: 0xB0 0x40 <pattern> - 0xB0 0x42 <pattern> -  0xB0 0x48 <pattern> -  0xB0 0x4A <pattern> These undocumented messages came in as: 0xB0 0x50 <pattern> - 0xB0 0x52 <pattern> -  0xB0 0x58 <pattern> -  0xB0 0x5A <pattern> Am I right to assume that these "5" based messages are an optimized transfer protocol for the second extra column?   Are more than two extra columns possible with the BLM?  Are there transfer options for more than one extra row? _____________________________  
  18. FS: SID Chips (6582a)

    Your timing is perfect...  I've finally ordered the rest of the parts to finish my SID boards that have been sitting half finished for a year or two...  I have 5 6581s, but I may as well fill the thing up while there are known good SIDs available.  Put me down for four, I guess. Any chance you feel like giving a bit of a break on the price for 4 of them?  Either way, let me know the total with shipping to Toronto, Canada, plz.  Thanks!
  19. LPC17 vs STM32f4 core

    I'm building an NG as a central controller for several synths, so that I'll be able to control parameters for a bunch of synths using one NG interface.  Right now I'm thinking the controller will have two 4x20 LCD displays, with 16 or 32 encoders, and about 40 buttons. Is there any real advantage to basing a MIDIbox NG controller on a STM32F4 core?  Or could I use an LPC17 core without any real difference in performance?
  20. LPC17 vs STM32f4 core

    Thanks - I have a couple of LPC17's lying around.  I guess I'll try the setup with one of those, and I can always upgrade later if I need to. I have a feeling this thing will eventually wind up with a ton of banks/pages, but I can cross that bridge when I get there...
  21. This is the discussion thread for the MIDIdocs article "Chords" in the Wiki.   Feel free to ask questions or make comments or corrections on the article in this thread.  
  22. edit: attached project.hex-es for the LPC and STM32f4 cores in case anyone wants to try this out - let me know if you notice any bugs.  The STM hex is untested - I haven't built my stm core yet.   How to use the Robotizer:   MENU+FX -> Robo - enters the robotizer page   Robot on/off - enables and disables all robotizers for this track.   Prob - the overall probability that any robotizers are applied.  This overall probability setting is combined with individual probability settings for each robotizer, so you can make one robotizer happen more often than others (eg: change notes often, but never skip them, and only rarely change the velocity).  Hold SELECT and use encoders to set individual robotizer probabilities (indicated by vertical bars beside each robotizer).  Individual probability is multiplied by overall probability, then compared with a random number.  If the random number is lower, then the robotizer will be applied.  A different random number is called for each individual robotizer.   Skip - skip some steps (play them at zero velocity)   Octave - changes octaves.  the selected number is the range - if "2" is selected, the note will jump up or down 0, 1, or 2 octaves.   Note - changes notes.  Cumulative with octave changes.   VelCC - velocity changes.  This robotizer is weighted using some bad math in order to avoid out-of-range numbers, and produce more musical results.  As a result of the way it's implemented, it's got a distinct character when the numbers are low (you'll get more loud accents if you keep the number low when you're starting with a velocity that's already relatively loud.), and a different character when the number is higher.   Len - changes the gate length.   Sustain - adds sustain to some notes.   NoFX - temporarily disables Echo and LFO.   +Echo - Adds echo to some notes.  Uses the settings on the Echo FX page, ignoring the FX enabled/disabled state on the Echo page.  In other words:  adjust the +Echo setting on the FX robotizer page to occasionally apply echo to notes, using the echo settings currently selected on the FX echo page.   +Duplicate - Adds FX Duplicate to some notes.  Uses the settings on the FX Duplicate page.     Prob, Skip, and NoFX do not have ranges, only probabilities.  The vertical bar and the number for these robotizers controls the same variable.   ROBOTIZER MASK:   - hold SELECT on the robotize page and use GP buttons to edit robotizer mask (indicated by GP LEDs).  Only selected steps will have robotizers applied to them.  Mask is 16 steps long, so it repeats from measure to measure.           ###############################   As a first MIDIbox programming project, I'd like to screw around with the humanize function a bit...  I'm thinking I'll duplicate it, call it humanize2 or something, and add a few enhancements.  To start with I think I'll make note, velocity and length each have individual intensity settings rather than just on/off, then maybe add a few other features, like probability of playing each note, delays and repeats, etc.  Then, I was thinking I might add a "humanize mask" - use the GP buttons to select steps in a measure, and the humanizing would only apply to the selected steps (so you could set it up to only humanize certain steps in each measure).   From a look at the code, at least the first couple of items on that list look like relatively easy projects for a C noob.   I'm wondering where I should store the data for this though - looking at the code, it seems that seq_cc_trk (defined in seq_cc.h and .c) is used to store the track data that's accessible via CC - eg: the current humanize values are stored there...  I don't want to interfere with the already defined CCs, and there aren't too many free slots apparently.  Since this is just a screwaround project I don't need my variables to be accessible by CC.  Is there another struct where track variables not accessible by CC are stored that I should use? STM-project.hex LPC-project.hex
  23. The next set of things I'm planning on experimenting with on the SEQ are some new generative track types - it'll probably take me a while to get around to this, it's a bit of a more complicated project than the robotizer thing. And I'll probably implement first, since doing that will help me understand how track types are currently implemented. But I thought I'd post this thread to discuss some of the ideas I have and see if anyone can build on them or if anyone has any other interesting ideas. Particularly to see if TK has any thoughts about how this sort of thing would best be implemented. MUTABLE INSTRUMENTS GRIDS DRUM ALGORITHM The first generative thing I'd like to implement is something like the Mutable Instruments Grids algorithm as a track type (an earlier version of the same algorithm generates the drums on the Anushri). It's basically an x-y map filled with different drum patterns. There are also "density" settings for the individual drums. Depending on the x-y coordinates and density settings, the algorithm generates some very interesting drum patterns without much effort from the user. More info on the algorithm here: http://mutable-instruments.net/modules/grids/manual Very useful when you're just messing around and need a backing drum track... It would be a very powerful addition to the SEQ, I think, because you could do a lot more with it than can be done on the Grids module - you could automate moves on the X-Y map, and density settings, etc. You could use it to control sounds other than drums, and some interesting stuff could be done with loopbacks. I have Olivier's permission to port the code over to the SEQ and release it under the SEQ license. This could be implemented with a normal-ish pattern based edit screen with new parameter layers that could control automation of the X-Y Coordinates, change drum densities, etc., as well as doing the more standard stuff like controlling velocity, etc. OR it could be implemented without a pattern based edit screen, and any automated changes to x-y or densities could be done with a loopback CC track.  Either way it would also have a config screen like a drum track type, with editing of MIDI assignments for the instruments as well as editing of the X-Y position and instrument densities.   On the SEQ, the algorithm conceivably could control many more drums than the Grids module can control.  This could also be very interesting combined with some random/robotizer-type features.   I haven't worked this out 100% yet, so suggestions are welcome. For experimental purposes I may implement a basic version of this in the FX menu, just because I understand how that menu area works pretty well now, and we could make it into a track type later if TK likes it. CELLULAR AUTOMATA CONTROLLED GENERATIVE TRACK TYPES This idea is still a work in progress, but I think there are some interesting possibilities with using Cellular Automata for generating changing patterns that aren't quite "random", but have recurring features without being repetitive. They're pretty simple to generate, and a track type that generated a new iteration of one or more cellular automata with every step would probably not consume too many resources. Those automata could be used as sources of bits to produce music in a variety of ways... I've attached a simple python script (rename it to [sOMETHING].py) that visualizes a 64 bit wide strip of one-dimensional cellular automata data. It uses the three neighbouring "bits" above each bit to determine the state of that bit, and for the leftmost and rightmost bits it loops around to the other side of the strip to get the third "neighbour". If you look at the code, there are several rules in there - just move the one you want to see to the bottom of the rules section. Or make your own (most rules create fairly boring results, but of the 256 possible rules in the script, there are many that go on forever and are interesting). Here's the output of one rule:   O OO O O OO OOO OO OO OOOOOO OOOOOOOO O OOO O O OO O OOO O OO O O OO OOOO OOOOOO OOOO O O OO O O OOO O O OOO O OOOOO OO OO OO OOOO O OO OO OO O OO OO O O OO O OOO OOO OOO O OO OO O OOOO O OO OO O O O O OOOO O OOO OOO O OOOO OOOOO OO OOO OOO OOO O O OO O O OO O O O O OOO OO OO OOO O O O O OOO O OOO O O O OO O O OOO O O OO O OOOOO O O O O O O O O O OOOO O OOO O O O O O OOOOOOO O O OOO O O O O O OO O O OO OO O O OOO O OO OO O OOOOO OOO O O OO O O O O O O O OO OO O O O O O OOO O O O OO O O O O O OOOO O OOOO OO O O OO OOOOOOO O O OO O OO O OO O O O OO O OO OOOOOO O OOOOO O OO O O OOOO O OO O O O OO O OOOO OOOO O OOOO OOO OO O OOO OOO OO OO O O O OO O OO OO OO OO OO O O OOOO O O O OOOOO O O OOO OO O O OOO OO OO OO OO OOO OOOOO O OOOO O O OOO O OOOOOO OOO OOO OO O O O OOO OO OO O O O O OOOO OO O O O OOOOOOOOOOO OOOO OO O OO O O OO OO O OO O O OOO OOOOO OOOOOOOOO OO O O OOOOO OOO O O OO OOO O OOO O OOOOOOO OO OOOOO O O OOOO O OOOOOOO O OO O OO OO O OO OOOOO O OO OOO O OO OOO O OOOOO O OOOO O O O O OOO OO OO O OO O O O O OOO OO OOO OO O OOOOOO O OOO O O OOOO O O OOOO O OO O O O O OO OOOO O O OO OO OOOOO OO O OOO OO O O O OO OOOO OOOO O OO OO OO O OOO OO O OO OO OOOO O OO OO OOO O O OOOOOO O OOOO OO OO OO O OOOO OO O O OOOO OOOOOO OOOO O O OO OO OOO OOO OO OO OO OOO O O OO OOOO O OO OO O O OO OO OO O OO O O OO O O O OO OO OO O O OOOO OO O O O O O OOO OOO OO O OO O OOO O OOOO OOO OO O OO OOO O OO O O OOO O O OOOOOO OO OO O O OOOOO O O O OOO OOOO O OOOO OO O OOOO OOO OO OO OOOO OOOOOO OO OOOO O OO O O OO O OO OOOOOOO O OO O OOOO OO OO OO OO O OOOOO O O OOOOO O OOOOOOOO O OO OOOOO O OO O OOO OOO O OOO OOO OO OOOOOO OO O O OOO OOO OOOOO OOO O O OO O O O O O OOOO O O OO OOO O O O OOO OO O OO OOO O OO OO O OO OOO OO OO O O OO OO O OO O O O O O O OO O O O O O OOOOO O O O OO OOO O OOOO OO OOOOOO OOOOO OO OOO OOO   Bits in a one-dimensional cellular automaton have only two states, but it's possible for each "bit" to have many states in higher-dimensional cellular automata... It's pretty easy for each "bit" to have many possible states - certainly easy to create a set of rules that would generate 128-state "bits" that could be used directly as MIDI data (or you could just pull 7 bits from some offset in a one-dimensional automata). Morphing two automata together could be interesting as well. Using the same "rules" approach, but checking against already existing data on the SEQ instead of checking the previous iteration of an automaton to generate new states could create some interesting dependencies, too. (like checking notes in the note stack, and applying rules to that data to generate dependent new data) These tracks could have "profiles" composed of a set of rules that would determine how the cellular automata data is processed into MIDI signals, and would make the output more "musical" in different ways, with configurable parameters.  Many different profiles could be developed for different types of track behaviour, even with different UIs and parameters.  The user could select different profiles to get the tracks to behave in different ways.  Or the automata could be used to automate changes to trigger layers like roll or repeat. There are a lot of possibilities.   I'm not sure if these CA based track types would use a 16 step editor like the other track types do, and have separate configuration menus, or if the edit screen for these CA track types should just show the configuration parameters.  Using a step editor as well as config menus could allow some neat automation of the CA parameters, but it might make things too complex. There are lots of other types of cellular automata that could be used. Conway's Game of Life is one that could conceivably be interesting implemented on the BLM, for example. ...I have a lot of experimenting to do to really flesh out this idea before I have any solid ideas on how it should be implemented (and there are probably several different implementations that would be useful), but I'd be interested to hear any comments or suggestions. There are other CA based sequencers out there, if you know of any particularly good implementations, let me know. ...and I'll set up a new branch of the code in the svn playground when I start experimenting with this stuff, since I don't want to break anything. auto.py.txt
  24. If you're having trouble running the binary, make sure you've installed the JUCE dependencies:   sudo apt-get update sudo apt-get -y install freeglut3-dev libasound2-dev libfreetype6-dev libjack-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev mesa-common-dev   And that you have set the executable bit on the BLM binary file - either right click on the file, select "properties" or whatever, and look for the permissions section - check "allow executing this file as a program" or whatever (not sure of the exact menu names and wording offhand.)   Or, from a terminal, in the directory where the binary is: chmod +x [NAMEofBLMbinary]   If you still have problems, run the binary from a terminal - that may show some error messages that will help diagnose what the issue is.  From a terminal in the directory where the binary is:   sh ./[NAMEofFILE]
  25. I got the BLM scalar app working on the Raspberry Pi (Debian) - I can use the Pi to run the Novation Launchpad BLM, it works pretty much perfectly, although it leaves some lit LEDs behind the current step indicator occasionally until it passes again.  No big deal...   The compiled Raspberry Pi binary is here:   http://www.boxx.ca/BLM-Rpi     Let me know if it works for you.   It segfaults if it is run from the terminal without X (TK, could this be made headless?).  So, set your Pi to automatically log in, startx, and then start the BLM emulator, and you've got a headless device to run the Launchpad BLM.   you might have to install the following JUCE dependencies on your pi: sudo apt-get -y install freeglut3-dev libasound2-dev libfreetype6-dev libjack-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev mesa-common-dev   Needs a powered USB hub if you're running the SEQ and two launchpads from the Pi...  But you can power the Pi from the same hub.   ############################   To compile it yourself: On your computer: Open the BLM scalar app in introjucer.  Add the following in the Extra Processor Definitions section: JUCE_USE_XSHM=0 JUCE_USE_XINERAMA=0 Save the project, and copy it over to your Pi.  I copied the whole MIOS32 directory over. On your Pi: sudo apt-get -y install freeglut3-dev libasound2-dev libfreetype6-dev libjack-dev libx11-dev libxcomposite-dev libxcursor-dev libxinerama-dev mesa-common-dev libjack0 (JUCE dependencies) Enter the JUCE project's Builds/Linux directory. Recent JUCE builds require GCC 4.7 - my compile was throwing errors before I did this: sudo apt-get install gcc-4.7 g++-4.7 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.7 sudo update-alternatives --config gcc ...and choose 4.7 ...then "make".  The compile is slow, but it worked for me - took about half an hour.