At the moment our MS3KOS2.0 Web Interface is set up in a 'developer mode', styling-wise. Some care needs to be applied to make the styling for the Web interface a little more professional and conducive to usage in a studio environment.

We have moved to a new Web-Interface technique in MS3KOS2.0, based on generating the user interface from a protobuf declaration that is shared between the Web code and the onboard MS3KOS Firmware. This enables us to easily add user-facing/-editable parameters to the Web Interface to support parameters required by the Firmware modules.

The new Web-Interface build artefacts therefore need to be generated and built into a final firmware filesystem (SPIFFS) image for inclusion in MS3KOS2.0. The steps required to do this right now are being manually performed - obviously we need to automate the build/package process to make this better integrated before release.

Hi,

current master branch fails to build with the following error message:

Submodule path 'MS3000-Firmware': checked out 'a3209033e5c4dffc534413e302a320ebdc528d9e'
fatal: no submodule mapping found in .gitmodules for path 'Tools/esptool-ck'
Failed to recurse into submodule path 'MS3000-Firmware'
Makefile:17: recipe for target 'MS3000-Assets/README.md' failed
make: *** [MS3000-Assets/README.md] Error 128

I wonder why we need the Tools dir?

Build environment:

Ubuntu 16.04
GNU Make 4.1
git version 2.7.4
PlatformIO, version 2.9.1
NodeJS v5.11.1

I started a special "Bicycle Light Mode" which allows two shifters to be used - one as the front light and the other as the back light - and also includes 'turn signals' for the front light. This mode should be finished and integrated into the standard Mode list.

It would be really awesome to make a new release NOW, JUST AS IT IS. Please release often release early ;)

Find a command line tool for that or add a static main for command line options
https://github.com/earlephilhower/arduino-esp8266littlefs-plugin/blob/master/src/ESP8266LittleFS.java

EDIT: this is probably not needed. Delete once it works

When we do a firmware update the complete SPIFS and everything else could potentially change so we need an automated scriot that automagically extracts all the custom images

bounciness factor can range from 0 to 2 ;)

(Moved this issue from Firmware repo to main repo where we are tracking all issues related to MS3KOS2.0 release)

Release the new MS3KOS2.0 binary image, which includes the new MS3KOS2.0 firmware, new Web Interface, new Resources.

Hi,

unfortunately GitHub does not support forking the wiki or pull-requests for the git-hub wiki.
Please merge my updates to UserManual from https://github.com/btittelbach/MS3000.wiki.git

cheers :-)

A common mode request has been a countdown timer - for example, the user enters the mode, selects a time period, and the MS3K immediately starts counting down - 15m, 10m, 5m, 1m, 30s, 20s, 10s, &etc.

I started programming this mode - this issue tracks further progress on integrating this mode into MS3KOS2.0.

Currently the Arpi mode is working, but requires extra controls for configuration:

• Source - MIDI Hardware IN or rtpMIDI input
• Destination - ^ Same as Above ^
• Arp type
• Arp style

These parameters need to be presented in a friendly manner - i.e. not just enums.

Also, we can re-use the Arpeggiator control in the Web Interface, instantiated multiple times with different note data, and then set the data when the user clicks the control on the web browser - this would mean nearly infinite #'s of Arpeggiator patterns can be created and selected by the user live, in realtime, and so some care needs to be given to how to add new Arpeggiator controls/patterns through the interface - i.e. perhaps we need a +/- button to add a new Arpeggiator control, and then of course 'save patterns' and so on ..

Only tested on OS X 10.10.
SiLabs VCP drivers are necessary to correctly get the USB serial device to mount:

https://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx#mac

After review of the older MagicShifter, it is determined there are other modes that we should port to MS3KOS2.0 - for example, Cliffords great single-pixel game would be a good additional mode to add.

Other modes too? Document them here please.

We'd love to know what you guys are doing with your 'shifters, so here is the place to answer the question:

What are you doing with your MagicShifter3000?

A friendly, easy to read User Manual is required for first-time MS3KOS2.0 users. This manual should explain all the basic features of the MS3KOS 2.0 -selecting modes, using the SysPrefs mode, individual documentation for each Mode, etc.

We should establish a nice style for the manual that makes it fun and easy to learn how to use the MS3KOS2.0 for all the various applications it supports.

The onboard WebInterface needs a pass to revise the styling, for example with the way the pixel editor is laid out, how to access the protobuf-derived sysprefs, etc.

It seems the shifters only accept non-encrypted connections when connecting to an access point. This makes WiFi pretty much useless[*] and is a severe restriction when planning to run multiple shifters.

I can only test in 1.0.0, because on 1.2.0 Wifi doesn't work at all.

[*] I don't even WANT to even start to consider running my home network unsecured...

We should save the last-used mode and restore to it after boot up.

just noticed random "blackouts" during image POV when Wifi is turned on (hotspot configuration). These dropouts are quite short and show up as a few missing "columns" in the image display.
(In my setup there was no active connection to the MS3000 hotspot. The dropouts seemed to disappear when i established connection).

Another issue which might be related: when Wifi is turned on, the "bouncing ball" display slows down considerably.... (thus the MS cannot be used as a tubular level anymore - which is IMO a very neat feature)

MS3KOS2.0 needs to provide the user with the ability to do OTA updates - I.e. cable free updates. This is implemented as of this date but requires further testing - I.e. firmware burns are working but full SPIFFs are not yet confirmed working.

Hi,

working with the MK3 Firmware I noticed that sometimes, newer platformio version, the wrong header file base64.h gets included. Maybe you should rename base64.h and base64.cpp from the lib directory to something like Base64_adamvr.

Platformio version 2.8.5 brings their own base64 implemetation! Maybe there is a flag in platformio.ini that gives the lib directory higher priority.

thx

Hi,

after resolving the Problem with #8 the build of the firmware fails:

make[2]: Entering directory '/home/XXX/MS3000_TEST/MS3000-Firmware/MS3KOS'
pio run -p pio serialports list --json-output | python -c 'exec("""\nimport json,sys\n\nobj=json.load(sys.stdin)\nfor y in obj:\n if "10C4:EA60" in y["hwid"]:\n print y["port"]\n""")'
Error: no such option: -p
Makefile:5: recipe for target 'run' failed
make[2]: *** [run] Error 2

Build environment:

Ubuntu 16.04
GNU Make 4.1
git version 2.7.4
PlatformIO, version 2.9.1
NodeJS v5.11.1

I was really excited to get my MagicShifter some years ago and still would like to play with it more than I did. It is a creative tool and I think that it has really a lot of potential, even with the current hardware of the MS3000

However, in the shop (https://hackerspaceshop.com/products/magicshifter3000?variant=10485196677) the magic shifter is listed as sold out. There was no activity on github for more than a year. And several important tickets (including one that prevents users to update to the latest software version) are unresolved.

Can we expect anything from this project in the future or do we have to accept that it is no more active?

after the battery was discharged to a point where i could not start the device anymore
i attached a 5V supply to the USB-port of the MS3000 to supply charge.

after several hours i noticed 2 leds showing green (i thought this indicated full charge)
I removed the power supply but the device was in a undetermined state (i could not activate any of the modes, the 2 green leds stayed on - I had to press the reset button ...)

maybe related: during charge i tried to turn the device on but it didnt come up (maybe because the battery level was still below threshold)

I flashed two Magic Shifter 3000 with version 1.9.1 yesterday. Everything is working fine until I try to connect another device via WiFi.

The very moment when the device is connected, the LEDs on the MS freeze and it is no more responding to any of the three buttons (reset and power off buttons still work of course).

Also the webpage on https://192.168.4.1 is not loading.

The only way to get the device back "online" is a restart.

I'm new to the MS3000 so I cannot completely rule out that I made something wrong though.

Hello.
I got my MicroShifter last week and the Usermanual is good.
I have problems to connect the pc to the Microshifter. Android 6 Device work after some trouble but I could only open the UserInterface with my PC (OK, old one with XP).

Some questions:
How can I delete images from the MagicShifter?
How can I backup Images?
What's that userImage.magicBitmap (dowladable with UserInterface).
The admin setup: Where can I give a Wifi-Password?

Thanks!
Roland

We should upgrade the debug package (and generally try to stay out of the way of these secvulns if possible..)

https://github.com/magicshifter/MS3000-WebInterface/network/alert/package.json/debug/open

I tried that several times now... when I flash the 1.2.0 bin using the writeFirmware script the shifter does as it should but when I try to access the webinterface it stops to do anything and the interface is never fully loaded... tried 1.0.0 and everything is working again...

We need an easy-to-use tool for end-users that allows them to take Firmware update products (.bin files) and flash them to their shifter's using a USB cable.

There are already a number of these tools out there - my personal favourite is BitBumper:

http://bitbumper.de/

We should test these tools and come to a final conclusion, to be documented in an MS3000 End-User FAQ, as to how users can easily do upgrades in the future. Since MS3KOS2.0 has OTA features this problem will hopefully dissipate over the next few months - but until then we should be armed with the details for how end-users can easily install updates going forward.

Hi,

I'm not really good with this newfangled git, but on a newly cloned MS3000 working copy, this happens:

% git submodule update --init --recursive
Submodule 'MS3000-Assets' (https://github.com/magicshifter/MS3000-Assets.git) registered for path 'MS3000-Assets'
Submodule 'MS3000-Firmware' (https://github.com/magicshifter/MS3000-Firmware.git) registered for path 'MS3000-Firmware'
Submodule 'MS3000-WebInterface' (https://github.com/magicshifter/MS3000-WebInterface.git) registered for path 'MS3000-WebInterface'
Cloning into '/Users/skowalewski/MS3000/MS3000-Assets'...
Cloning into '/Users/skowalewski/MS3000/MS3000-Firmware'...
Cloning into '/Users/skowalewski/MS3000/MS3000-WebInterface'...
Submodule path 'MS3000-Assets': checked out '0739a9a47d832aa3ff5fc64c82ec1d1ff582f295'
fatal: remote error: upload-pack: not our ref c732082a141bf0cddb72344a1394c51014a6c17d
Fetched in submodule path 'MS3000-Firmware', but it did not contain c732082a141bf0cddb72344a1394c51014a6c17d. Direct fetching of that commit failed.

Environment:
o Catalina

At the moment, to build MS3KOS you must do the following braindead things:

1 // comment out the min() and max() macro's from Arduino.h. This is braindead of Arduino to do these macro's, but so be it - developer beware!

vi ~/.platformio/packages/framework-arduinoespressif/cores/esp8266/Arduino.h

line #253 .. 254 should look like this- i.e. commented out:

`#ifndef _GLIBCXX_VECTOR
// arduino is not compatible with std::vector
//#define min(a,b) ((a)<(b)?(a):(b))

//#define max(a,b) ((a)>(b)?(a):(b))

endif

`

(Please note: these macro's are buggy, do not use them! Ever!)

Note: you must do 'make clean' after this, to rebuild the .pioenvs build-dir!

2 isSpiffsFilenameValid
At the moment, we use the SPIFFS openDir API inappropriately. For that reason, stick a return 0 in the isSpiffsFilenameValid method, thus:

vi ~/.platformio/packages/framework-arduinoespressif/cores/esp8266/spiffs_api.cpp

bool isSpiffsFilenameValid(const char* name) { return true;
We will address the inappropriate filesystem usage in a separate issue.

Note: you also must do 'make clean' after this, to rebuild the .pioenvs build-dir! In fact, just generally, always do a clean build .. i.e. "make clean test monitor" ..