Arkay

Members
  • Content count

    76
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Arkay

  • Rank
    MIDIbox Newbie
  • Birthday 03/02/1970

Profile Information

  • Gender Male
  • Location Melbourne, Australia
  1. +4 from me, to round out a full set of beer goggles  :w00t:  :hyper:  :geek:  :frantics:  :D   Thanks for all the awesomeness this site provides and the undying efforts of T.K keeping it all running and ticking over with endless improvements. Also a hat tip to Wilba, Hawkeye and the many many frequent and infrequent contributors that make this site so awesome.  Merry Christmas to all! :smile:   @borfo, great idea for a thread ;)   Cheers,   Arkay.
  2. Sweet :)  Lovin' the Trance.
  3. Problems with uploading MIOS studio

    I run GNU/Linux and have no problems with a variety of midi equipment.  Including a Roland UM-1X.  Sounds to me that it's the UM-1G and/or the cheap generic interface that is likely the culprit.  Did you checksum the downloaded firmware before flashing?  Maybe you had a bad download?   Cheers,   Arkay.
  4. How 2 play chords

    Awesome work T.K!  The quantity and quality of your work amazes me :)   Cheers,   Arkay.
  5. Lasercut Acrylic Case+ Frontpanel for SEQv4

    MaG2k, Glad you found a workaround with the software. It's an odd one. I can't help with your other questions though. Smokestackproductions conversion just worked for me after a short learning curve in the software to add the extra midi ports and move the SD slot. But I really know little to nothing about designing something like this from scratch in CAD software. This case was my first foray into laser cutting at all. I can see why it becomes addictive though :D Good luck with the case! Cheers, Arkay.
  6. Lasercut Acrylic Case+ Frontpanel for SEQv4

    MaG2k, Not sure what is happening with your inkscape but I can confirm that I used those files in inkscape (on Linux not that it should matter which OS you use), and modified the original to suit before sending off to Ponoko. Everything worked fine when I did it so I'm wondering if there is some setting or oddity in the way inkscape is opening the file? Defaulting to the wrong units of measurement or something? I can't exactly remember now if I used the original files in post 1 or the modified files that flip posted in post #18. Have you tried opening flips in inkscape to see if they exhibit the same issues? If they do then there's something off with the software as it all can work fine with inkscape and either one or both sets of files. I can check on my work laptop next time I'm there to see if I still have the modified files if that will help? Cheers, Arkay.
  7. How 2 play chords

    +1 for more tutorials. I'd love to see some too. The v4 is so powerful and everyone could benefit from such detailed documentation. Even better would be a user posted tutorial forum where questions on technique could be answered by other members, preferably in video format. Members need to be willing though. If I felt confident enough I'd have a go, but sadly I don't. Would be awesome if an instructional video library from the simple to the complex could be built up! The original videos from TK inspired me to build the v4 and the other videos I've found of the v3 in use have been very inspiring and useful. Just not enough of them :) Cheers, Arkay.
  8. FS: Cheap MBSEQ desktop panel (1-off)

    That's looks awesome. Nice one :) What center knob do you have on there?
  9. MBSEQ CC/Velocity Automation Question

    T.K.   I did find the ability to change the function of the datawheel today while I was messing with the new functionality!   Happy to go with your suggestion above and thanks for the effort and the mods :)   Cheers,   Arkay.
  10. MBSEQ CC/Velocity Automation Question

    T.K.   Yep.  All fixed.  Thanks!   One final suggestion.  At present after you set the the active step the only way to get to another inactive step is via ff/rew.  It seems a little unintuitive that you can't scroll to the final step with the datawheel and then adjust it's value with it's specific encoder.   Just wondering if this might make more sense:   1. scroll to the step you wish to be the active step, denoted by > <  (all button currently off) 2. turn all on (locking in active step) 3. scroll to the final position via datawheel or ff/rew 4. adjust value with encoder (triggering ramp between active step and inactive step being modified). 5. turn all off to complete.   That way you can still scroll around the pattern with the datawheel without changing the selected active step.   Would this have any unwanted side effects with the all function itself?   Cheers,   Arkay.
  11. MBSEQ CC/Velocity Automation Question

    Just tried it out.  That's awesome and so quick to edit what I needed to do.  Implementation is obvious and works really well.     e.g. for those reading the thread if say you want to sweep to a midpoint in a pattern you can set the active step to 64 (midpoint of a 128 step pattern), then set step 0 and 128 to a value of 0 and you've got a perfect 0-128-0 ramp peaking in the middle of the pattern.   A 32 beat drumroll is as simple as selecting step 0, velocity 0, hitting "all", then changing step 32 to 100.   I think I found a bug though.   With the all button depressed if you scroll from position one through to position 17 and greater using the main encoder the display doesn't switch to the next set of 16 steps unless you hit the ff button to force the jump. i.e. if you use the main encoder to scroll through a display boundary the display isn't following the step selection.   You can see by the value next to the cc# that the steps are correct but the display remains static only showing the 16 steps you could see when "all" was selected unless ff/rew are used.  As a result if you scroll all the way to the end of a 128 note pattern via the encoder, changing the 16'th encoder results in you editing step 16, not step 128.  To see step 128 you'd either have to ff to it or turn all off.   Loving the functionality already.  Thanks for implementing this T.K.!   Cheers,   Arkay.
  12. MBSEQ CC/Velocity Automation Question

    T.K. Man your are quick :) You sure there's not three of you working on all the things you do!!! I'm out at present but will be trying this out as soon as I get home. Handling sounds fine and I doubt I'll be able to come up with anything more ergonomic but won't know till I try it. Initially I'd thought of a shift like function i.e. Hold select, press a step or tweak encoder to set step start position and initial value, release select, navigate to end position via whatever method user chooses, hold select, press the final step or tweak it's encoder to set the end step and final value, release select. Which seems logical to me. But so does what you've already done ;) Awesome work! Cheers, Arkay.
  13. MIDIbox SEQ V4 Release + Feedback

    It makes a boatload of sense to my workflow too.  I'm forever changing midi channels on the master keyboard (which takes a number of key presses)... Now I can just change tracks on the sequencer  :smile:   Excellent modification.   Cheers,   Arkay.
  14. MBSEQ CC/Velocity Automation Question

    T.K., I see what you mean by the dynamic changes and that would be an awesome addition but I also understand why the logic to achieve that is soo much more complex. The static/circlon way would also be of great use. If those pre programmed steps can then be all raised or lowered simultaneously and globally across the track like the circlon then that provides a "live" aspect to it's usefulness. The only other option that I presently see (besides the LFO which works awesome BTW), is to manually edit each step via encoders which is cumbersome. The lfo is great, but is more aimed at continued wavy automation. An editor based solution allows specific ramps to be used, without manually completing each step, but also allows for irregular shaped envelopes. The lfo with a sine wave for instance will give you a nice phase via the amplitude of the wave, but if I wanted to construct a: 0 to 29 step rise over 128 values then a sharp drop down to 50 over the next 30 steps then a further drop to 10 over the next 40 steps it wouldn't be possible via lfo and the only way would be by manually adjusting the values of every step throughout the pattern (100 edits) when in reality 3 "ramp edits" are all that could be required: start 0 end 29 range 0-128 start 30 end 59 range 128-50 start 60 end 100 range 50-10 I absolutely love the idea of the high resolution sweep via higher ppqn but that only matters for the use case when the number of gate steps is less than the range of sweep steps required. I do see the complexity in implementation and possibly even issues with understanding and obviousness of what is going on to the end user from a UI perspective. In reality if a user needs a higher resolution sweep there's nothing stopping them from using a higher resolution for the entire track and then distributing the cc ramps via the same static edit methods. i.e. Setting a start/value and end/value pair and having the editor generate the static steps in between, at what ever resolution the entire track runs at. Obviously large sweeps over small distances would result in low res audible jumps. In that case I probably wouldn't do it. This function is really of use over longer periods. Like increasing the velocity of a snare from 0 to 100 over 32 steps for a long snare roll for instance. Without the ramp function the end user must calculate the size of the increase per step manually and then input that velocity data to 32 steps, one at a time. Possibly a different way would be to change how the sequencer presently works and have a highest ppqn effects track that always runs along side the standard note data in a track when the track contains cc data. i.e. The effects track is always at the maximum resolution and any statically made ramp type edits would automatically yield the smoothest changes between two endpoints. Allow a max of 4 cc numbers per effects track and remove the notion of tracks with gate and cc data combined. So a pattern is either just note date at it's specified ppqn, or note data + a 384ppqn effects track. That might not be practical from a speed perspective, just thinking out loud. I think straight ramp (vector) generation between two points would be a great addition as a time saver, especially if it's easy to implement, that's a win/win :) If it could be made to extend past a single track in song mode, then even better! The higher res methods could be a longer term goal? Cheers, Arkay.
  15. TK,   Works perfectly for me under Arch Linux. Not what you need to know with regard to Windows but feedback none the less :smile:   Cheers,   Arkay.