#42

Thanks, but I tried the Octatrack and like many others I couldn’t digest and retain the UI.

#43

Many of the sequencers mentioned in this thread have unquantized recording modes and/or high note resolution. UI/workflow is so personal, it might require trying a few to get a handle on it.

I’m curious, why hardware? I’m aware of the typical answers to that question, but I’m curious what your personal reasons are. Many people find that sequencing in a DAW is far more intuitive than it is with hardware, especially unquantized sequencing.

2 Likes
#44

Usual answers. I don’t want a laptop in stage. The last DAW I actually enjoyed working with was Opcode Vision. I’m afraid as I get older I find it more and more difficult to muster the energy to work with software which is so clearly geared towards not me… that said it looks like my best bet would be to create a template in Logic and construct some sort of midi surface for real time recording/playback.

2 Likes
#45

I’m some way towards developing a live performance loop-pedal style 96ppqn midi sequencer - free software and runs good on my linux laptop but it’s currently too horribly innefficient to deploy on a little arm board as I originally intended. However it doesn’t require the user to look at a screen - just use the buttons/leds on a quneo for all the ‘UI’.

Currently my music hacking is focussed on grains module for aleph in order to coax some suitable weird sounds from my guitar. But I will be picking this project back up some time in 2016…

https://github.com/rick-monster/cl-alsaseq

I should make a video demonstrating my setup with external midi clock, boomerang pedal and the looping software. Should also add that this is a prototype of something very much customised to my own needs and preferred self-imposed limitations - probably not something you should try to download and expect to work with another setup. I post the link in case anyone is interested in the code really…

5 Likes
#46

I need to get me some more of these

2 Likes
#47

how inefficient is it? We ran a version of puredata on the super tiny gumstix Overo boards and managed to get them to do a bunch of intensive audio processing without problem. Our pd distribution is here if that’s useful to compare https://github.com/circumstance

1 Like
#48

In my recent search for a sequencer I came across this which should do exactly what you’re looking for:

(his MidiALF sequencer also looks really awesome…)

#49

Not what I’m looking for I’m afraid. Not sure about OP. My discussion with the developer is at the bottom of this page http://midisizer.com/midirex/midirex-reference/

#50

I couldn’t quite tell from the comments what specifically it was about the midirex that wouldn’t work for you?

#51

From the discussion -
Track are not independent, they play their own set of notes on their set channels. The total length of a loop is defined by the length of a longest track. Shorter tracks are repeated inside the loop…
Track lengths are quantized down to a beat.

Back to me -
So really real time is not possible, and independent loops are not possible.

#52

These are really common limitations. Still think Logic may be your best bet, but perhaps something like Squarp Pyramid might work.

#53

but it’s a heck of a way to meet new friends…

#54

Re-Pyramid - I don’t think so. Still needs to be initially tempo based.
I think I may have found something in M4L - http://sonicbloom.net/en/loopo-max-for-live-midi-looper-for-more-intuitive-recording-of-session-view-clips-improvisation/
I’m experimenting with the demo now.

1 Like
#55

As I’ve turned to software based options, for now at least, I’ve started a new thread - Real Time (sorta) Midi Looping

#56

Oh - it’s really inefficient. So the way I wrote it (common lisp) every midi message decoded to a fairly verbose human-readable lisp plist. Also I run a dedicated clock upsampler in it’s own thread to get the 96ppqn going in midi slave which I don’t think is particularly cheap.

3 threads are chucking round these disposable plist structures using concurrency channels and using erlang-ish pattern matching to detangle the mess - seems to be ahem exercising the gc somewhat. Haven’t profiled so I can’t say for sure but pretty confident I can refactor to just store midi messages as numbers and get a huge win.

These are some inherently fiddly problems I discovered in designing a midi looper:

  • ‘upsampling’ the 24ppqn clock in slave mode (solved)
  • hanging notes when you stop recording a loop before releasing a held note (solved)
  • flams when quantising incoming midi (can’t remember if I have quantisation yet)
  • pressing drum pad momentarily before loop record (not solved properly yet, just shove everything just before the button press on beat 1)

come to think of it I’m nowhere near ready to add the fun/cool features that made me want to write my own midi looper using lisp in the first place:

  • ‘improvisation’ algorithms where the machine can randomise played-in patterns a bit to make things less predictable
  • arpeggiator which can be loaded with any played-in pattern
#57

the other reason I wanted to roll my own was to get a system that allowed me to start off in free time (like my boomerang looper with the guitar), proceed in loop-synced time (lengths quantised to time master loop), then have the option ‘hint’ the pulse to the looper software with some taps on a controller or a nearly-right incoming midi clock. If the piece of music gets locked onto a tempo pulse, loop length quantisation becomes 1 beat.

Actually I might be able to pull this feature off - but the boomerang wouldn’t fit quite right into that workflow, so I’d end up screwing with sooper looper or something and the whole thing gets even more heath robinson…

#58

That is exactly what I’m looking for.
I made a bunch of music with Oberheim Echoplex (v similar to Boomerang) and I’m looking for similar workflow feel with midi dim hope I might be able to tie this to modular at some point. Please keep us posted…

#59

Future Artist showed a MIDI Looper at Musikmesse last year. I would guess it’ll ship some time this year, sounds like it could be much what you’re looking for.

http://www.future-artist.com/home-en/product/

1 Like
#60

Just dug into the alsa api a little bit & found the alsa-event->rawmidi conversion. So I’m going to do a major refactor of my midi looper software, simplifying the code & making everything run a lot leaner by passing midi messages as lists of 12 bytes rather than complex nested plists. That should get things cooking on embedded linux…

Also aleph integration through a native lisp->usbSerial backend is on the cards. Planning to come at this this initally from the aleph side, fleshing out out the bees<->host serial protocol. OSC will require a bit more thought and research so this will be midi & aleph-serial only for now.

1 Like
#61

Back to thinking about the boomerang workflow, and whether it’s possible to create a control-signal looper that uses the brother-sync protocol common to boomerang & echoplex, rather than relying on pre-ordained midi clock or similar…

I want the ability to output clock at some arbitrary sub-division of the master loop (tap-hinted), enabling to slave step-sequencer off organically-timed boomerang jams. Made some progress last night - bro-sync messages from boomerang were relatively easy to sniff off the linux raw midi device file (/dev/midi3 on my machine).

Also that approach highlights how dumb it is to bind common lisp to alsa sequencer. alsa seems to drop bro-sync messages on the floor - they’re malformed sysex so the best approach should be a custom midi-message-decoder state machine, rather than hooking onto existing midi library. Probably going to result in much faster code that should run no prob on beaglebone - here’s hoping for 2 birds/one stone!

Out of curiosity any other boomerang/echoplex users on here?