problem with MacOS #58
Comments
raphaelquast
added
bug
|
Hi there! I’m not having much luck getting the beatstep working with this script. I’m on Live 10 and Mac Big Sur. I’ve moved the script into the Midi Remote Scripts folder. When I boot up live and plug in the BeatStep, nothing seems to happen - it acts as a standard midi controller and I don’t seem to be able to access any of the 6 pages enabled by the remote script. How can I help debug this? I have attached a section of the live log.txt file from the time I booted and setup the script. Cheers! Click here to view log.txt |
|
Hey, Here's what I found so far (via quick tests on Mac's from other people):
Right now I have no clue where or why the error occurs.... and without a Mac at hand I'm also not really sure how to proceed debugging this... (but if you are actually willing to help, I'm certainly willing to spend some time to get to the bottom of this!) Do you know how to work with python?
Another thing would be to check if there's actually a difference when using Ableton 9 / 10 .
Cheers, Raphael |
|
Hey, thanks for the quick response. I'd love to try and help out. I'm testing out a beatstep for a month, so maybe we'll be able to figure it out before I return it if I don't buy it. I have some familiarity with python, and can definitely run some scripts. I took a look through the library a bit, but am not familiar with Ableton's APIs. Can you advise to get started executing the scripts outside of ableton (/ with a tool like mido?). Otherwise, I'll try and poke around when I have free time. Aside - I don't own Ableton 9 (I upgraded directly from 8 -> 10). |
|
Hey, awesome! Then let's give this a try!
The first thing I would like to check is if the setup of button- and encoder behaviours works on MacOS without Ableton involved.
Thanks a lot for helping out! By the way... you can get any previous version of Ableton if you log in at ableton.com and go to "Download-Archive" |
|
Sounds good! I have tried downloading Live 9 but the beatstep did not work as intended either. So perhaps this is something specific to being on a Mac in general. |
|
thanks for trying out! ....well that again adds to the confusion... I still can't see a reason why the script would work on an old MacBook with Ableton 9 but not on a new one... I've prepared a gist that shows how you can change the behavior of BeatStep's buttons & encoders via python: first you need to install When you run the script you'll get a class object
I've added several commands in the script so you can see whats possible. What I would like to know is if all those commands to what they are supposed to do...
Let me know if this is clear to you or if you need further help to test this! |
|
Thanks for creating the script. I managed to get it working, but I had to make these changes: # didn't work:
# setup I/O for the BeatStep controller
# x = beatstep_io(outport='Arturia BeatStep 1',
# inport='Arturia BeatStep 0')
# works:
x = beatstep_io(outport='Arturia BeatStep',
inport='Arturia BeatStep') |
|
Hey, well that's good news! 😄 Does this also mean that all settings had the desired effects? e.g.:
|
|
Great! I tested every button and knob and this is the output of it. controller outputFrom my reading of your script, lines such as this: # set button 1 to "toggle" behaviour
x.set_B_behaviour(1, 0)should be making it so that when button 1 is pressed it simply turns on and stays on, which is not the case when I tested the beatstep. |
|
Thanks for testing! From the log it's pretty clear that the settings didn't work... Did the LED's work? # turn button 1 red
x.set_B_color(1, 1)I'll think about why this does not work on a Mac and hopefully come up with a new plan soon 😅 |
|
This is quite strange. After testing changing a custom colour as you suggested above, pad one and pad 5 seem to be set to "toggle" mode. Perhaps I need to install some arturia software to set the beatstep to some kind of default? |
|
well, I've started expecting strange results with this issue... but you are right, this is indeed unexpected... in general you should not need to use any Arturia-software to initialize a default config since the script
QSetup().set_B_color(1, 1)
>>> (240, 0, 32, 107, 127, 66, 2, 0, 16, 112, 1, 247)What puzzles me is the fact that those codes do not seem to work on particular MacOS versions. For now i see several ways to go:
|
|
Awesome - thanks for the detailed comments. Here are the results of following your steps:
There was a lot of output here; Click to view:
Hope this helps! I appreciate your prompt debugging help. I'll buy you a coffee :) |
|
Hey, Thanks for the coffee! I equally appreciate your quick responses!! unfortunately we reached a dead end here... all messages are exactly as expected 😞 ... here's how to check it in case you're interested: from QSetup import QSetup
Q = QSetup()
button = 1
setdict = {'mode': 9, 'channel': 1, 'cc': 44, 'off': 0, 'on': 127, 'behaviour': 1}
for what, val in setdict.items():
print([i[2:].upper().zfill(2) for i in map(hex, getattr(Q, f"set_B_{what}")(button, val))])so we're back to identifying why python seems to have problems sending MIDI sysex-messages... I searched a bit if anyone had similar problems but there's not much info out there on this topic... some ideas that could be worth a try:(I'm no Mac user so I guess you can judge the usability of the ideas better than me) Troubleshooting USB MIDI devices on Mac
Mac OS X - Problems with MIDI devices after an update
Mac OS X - How to Re-Configure Your MIDI Studio
|
|
Awesome - thanks for the resources. I will poke around the midi internals on mac. I wonder if something on Big Sur changed things, or perhaps a python version / dependency issue...? Anyway, I'm just guessing in the dark. If I come up with anything I will let you know! |
|
hey, did you have any luck with the MIDI Monitor tool? I digged a bit deeper and I'm more and more convinced that this might actually be a MacOS MIDI driver issue... in 2014 somebody wrote on a related Java-problem: Send sysex message with Java
one might think that such problems are fixed 8 years later but you never know 😄 it is really strange that there is literally no info on sending sysex-messages on OSX aside of using existing software-tools.... right now the only option I see is to get in touch with either the Since I don't own a Mac it does not make a lot of sense that I start such a discussion since I can not help debugging in any way... (however I'd be happy to join the discussion and help as much as i can to solve this! ) |
|
OK... I got a final idea... maybe MacOS is simply choking on too many simultaneously sent sysex messages... @teesloane can you try to use this branch hardware_setup
... it might happen that the LED response from BeatStep's internal initialization is interfering with the sequence... (afterwards the script will NOT work! ... this is just a test if this could be the problem... i sincerely hope this is the problem 😄 |
|
Hey - I I haven't tried the midi sysex stuff yet - but I will try and get to that before the weekend. I did try putting your branch into the midi remote scripts and followed your steps. I've attached a video of the results. Interestingly, when I plug the BS in it does it's normal sequence and nothing happens, but if I disable and enable the control surface, it seems to be lighting up in the manner you suggested. telegram-cloud-document-1-5005903409916674615.mp4 |
|
hey, awesome! 🥳 thanks again for the quick response!! if you look closely you see that the sequence is actually also running when you plug the controller in... it is just inter-mixed with BeatStep's startup sequence (which turns all buttons off all the time so you only see a faint blinking of the top row buttons) I think now we're actually on the right track!
some ideas I found on the way why this might be happening:
I think we can skip the MIDI Monitor stuff for now and I will try to fully incorporate this way of sending the sysex messages for the startup-configuration and the layer-change mechanisms... (It'll require quite some changes so be patient 😄)
|
|
Great! It sounds like this is moving in the right direction.
I am currently connecting the beatstep through my monitor, which has |
|
well, I'm not sure about that... but it would not be the first problem I've encountered with usb-c.... anyway, a proper implementation that works on any connection would be a nice thing to have! could you try the hardware_setup branch once more? (just added 1 tiny commit) |
|
Sure thing. Here's me with the latest change from hardware_setup, plugging it in, removing the control surface and adding it back in. 2021-05-27.19.40.44.mp4 |
|
Thanks! If you don't mind I'd like to test the progress every now and then... to that I don't stumble upon pitfalls along the way... |
|
Sounds good. I'll rent the beatstep for another month (should have it for another 45 days or so). Good luck - I'll keep an eye on the pull request, but feel free to ping me here if you need something tested! |
|
Hey, thanks for that! I really hope we get this running in the next month... I've tested several approaches for sending the messages but the general Tasks-module that is used for threading is so horrifyingly undocumented that I got annoyed (and somewhat lost) on the way... 😄 However I've now implemented a straight-forward "message-scheduling" approach that simply makes sure that there's a slight delay between all messages... |
|
Hey! I gave 72 (cloned the repo, checkedout the branch "hardware_setup") a try but didn't see much difference. I'm not totally sure how layer activation works, but based on the images in your readme, I tried activated the telegram-cloud-document-1-5026301936182231505.mp4 |
|
Damn, i really had my hopes up for this one... Thanks for continuing to test my ideas! (I still have no way to reproducethis on my pc so without you i would not be able to track this down... You definitely got yourself a place on the "thank you" list of the next release 😅 |
|
Hey, guys! Big thanks to author and Teesloane for debugging attempts. I've tested the scripts on MacOS Big Sur (11.4), with both Live 10 and Live 11. the default Beatstep_Q scripts (master branch):Live 11: initialization failed (no backlight for random number of pads during init), working inproperly. I've gone a little further and made two separate branches to test with: [TL;DR: It seems that Live 11 on MacOS have an issue with MIDI Remote Scripts itself. Live 11 dropping messages scheduled for the one tick, even if optimized=false parameter set. One tick is 0,2 seconds (if I'm not mistaken here), and sending one command per tick - is too slow for work. ] branch 'setup sync':Made indication working in parallel with the pads/encoder setup process, tried to add parameter optimized=false for delayed 'send_midi' calls according to Remote Scripts API documentation, to avoid commands dropping. Live 11 working only with INDIVIDUAL_MESSAGE_DELAY set to 1, but setup/init process is too slow for normal workflow (you'll need to wait for 10 seconds every time you press 'Shift' button before you can use pads). If you change the delay (INDIVIDUAL_MESSAGE_DELAY) to smaller value, Live will ignore some of the commands (seen by gaps in pads backlight sequence). Probably, Live 11 dropping midi messages scheduled for one tick. Setting INDIVIDUAL_MESSAGE_DELAY to 0,5 made Live to drop a half of messages for pads/encoders setup (visible by the backlight missing for a 8 pads) as a result, only half of the encoders/pads worked. Scheduling messages/commands for another ticks is too slow for normal work. In Live 10 the scripts working well; commands, scheduled for one tick executed at the same time, which is seen by pairwise switching on of the backlight on pads, while INDIVIDUAL_MESSAGE_DELAY set to 0,5. The value of 0,01 is better for more convenient workflow, as all the setup/init process executed nearly instantly. For live 11 such value made it ignore all the messages, but Live 10 working great. branch 'optimized_false' :All send_midi calls executing with the parameter 'optimized_false' to avoid messages dropping. Backlight sequence executed via schedule_message independently of pads/encoder setup. Live 11: initialization sequence executed visually correct (no gaps in backlight, because it all set in other ticks), but pads working incorrect, 'Shift' mode activates only on second press of a button instead of button hold. Hope, this helps somehow. |
|
@DTRS Unfortunately I don't have a lot of time right now to work on this issue myself... ...but I'm of course happy to provide any Ableton/python help I can give and I'd accept any pull-requests that help to get the script working on Mac + Ableton11 Do you have any Idea why Ableton11 is loosing MIDI messages on MacOS on the way? Also I get from your comment that the script is working just fine on your Mac when using Ableton10 ? |
|
Hi! Any progress on the Mac side ? :-) Recently bought a beatstep and I'm trying out your scripts without success. |
|
Hi, unfortunately there has not been any progress on the MacOS side... I tried my best, but so far I was unable to identify the actual cause of the problem on MacOS, and since I do not own a Mac myself debugging this is really hard... It seems that somehow MIDI messages get lost on the way but there's really no indication on why this is happening (and on Windows everything works just fine). I'm happy to provide feedback and accept pull-requests that tackle this problem, but at the moment I do not have the time to look into this myself. |
Yes, right. Works as intended (device controls working, arming/muting tracks, adding scenes, etc.) with Live 10.1.1 @ BigSur 11.5.2 (tested again at the time of writing this, sorry for the delay), with this settings for control surface in Live: |
|
@DTRS thanks for the clarification... it adds to the general confusion on what's going on here 😅 It seems that there must have been some changes in the way MIDI sysex messages are sent on MacOS in Ableton11 but there is no indication at all what changed and how one should adjust to those changes... |
|
I also tried again on Big Sur 11.5.2 with Live 10.1.41 with same settings as @DTRS. When using the knobs, scrolling in the slots is sluggish and not usable at all. Also the clip start/recording is not working. I searched the net for solutions, and arrived here : https://www.reddit.com/r/ableton/comments/86zepx/help_using_arturia_beatstep_as_both_surface/ "I found a better solution guys and is to store the Control Surface mapping to a memory slot on beatstep i.e. memory slot 2 so you can recall it anytime you want, i´'ll share the map on a drive link but if you can create mirror or permanent links that will be useful for everyone. https://drive.google.com/open?id=1NzRv9GmtoqMSZfPzViUcYggdjLwPDfZw hope this helps." So I uploaded via the Arturia Midi Control Center file "ControlSurface.beatstep", saved it to slot 2, and I'm using this with success. All knobs, pads are working fine in control surface mode (beatstep), no hick-ups. :-) |
|
@Acidity2012 thanks for the comment! (and sorry for the late response) you mean all functionalities are working if you just save & load the script to slot 2 ?
can you confirm that switching layers & changing the MIDI notes actually works as expected? |
|
Hello - I'd love to have this working with my Beatstep and Live 11 (currently OSX 10.13.6), but not working as detailed in this thread. I think @Acidity2012 is writing about using an alternative control surface mapping, not Beatstep Q, with only a fraction of the functionality. I'm afraid I don't have the skills to help you fix it, but I hope you can find success. |
|
Hello...I am having the same problem. And I bought a beatstep to use this script! I am getting the "frozen lights" in the initialization of the beatstep as described at the start of this thread...The script was installed properly, and I can see the red rectangle in Live signaling that I could launch those clips (Beatstep_Q is active, beatstep controller is not runnign it though...). anyone has fixed this issue yet? What can I do?! |
|
Hey, @Helder-boop I really tried hard to get my head around this problem, but after a lot of try-and-error, I'm again completely lost... The problem I've identified so far is that somehow MIDI messages get lost along the way when the script initializes the controller. How or why this is happening on MacOS (and not on Windows) remains a mystery and I haven't found any clue yet. Unfortunately solving this will definitely require a bit of python-code... (and maybe even some insights on MacOS MIDI internals or whatever is causing this) |
|
Thank you so much for taking the time to reply raphaelquast. Yes, it is a bummer, and I am willing to try something, if you want me to, and if you can explain exactly what I should do. I do not have any knowledge of coding unfortunately. Is this an issue for all macOSs and all Live versions? Is it worth waiting/hoping for the issue to be resolved, or would it be better to just return the controller? It is a shame indeed, I was quite excited about this! I was hoping to use this instead of Push or something like that! Best. |
|
@Helder-boop Well without any programming knowledge it would be down to me to fix this and as I said before, without a Mac this is quite impossible since I have no means of reproducing the issue. I tried it on a quite old MacBook with Ableton 9 and (quite puzzling) the problem did not occur... On a newer one (don't know the explicit OS version) the problem was as described by previous users. I'm really sorry to disappoint you in that manner, but I doubt that this issue is going to be resolved soon... (except somebody shows up with an idea on what is going on) |
|
Hi I would be happy to help here. I am no magician but I own a Mac, Ableton a Beatstep and I know some python. So have your testscript running and i was wondering if I should run a midi analyzer on a raspberry Pi to analyse the MIDI signal transmitted over USB. What are your thoughts about that approach? |
|
@dwi-iwb Hey, awesome, thanks!! I'd love any new insights on this! Analysing the transmitted MIDI signal sounds like a good approach to get a better idea on what's happening...
I'm happy to help wherever I can to get to the bottom of this! |
initialization is not performed properly on some systems using MacOS + Ableton 10
The text was updated successfully, but these errors were encountered: