Windows build

[NothanUmber]

Trying to compile MEC for Windows. Tried to set SP_LIBUSB_DIR as environment variable.
Now if I execute "echo %SP_LIBUSB_DIR%" I get: "D:/dev/libusb"
E.g. core.c resides under D:/dev/libusb/libusb/core.c etc. as expected by CMakeLists.txt.

Occurrently cmake is not accepting it though, still getting "Did not find libusb". Where would SP_LIBUSB_DIR have to be set when not in the environment variables?

When temporarily hacking CMakeLists.txt directly then cmake succeeds. But the project still doesn't compile e.g. because it doesn't find a whole bunch of "config.h" files (would I have to compile the external libraries separately first?).
soundplanelite/MLDebug.h also seems to want to have Juce.
And min is misinterpreted for a macro (#define NOMINMAX or unsigned l = (std::min)(history_,(unsigned long)PIC_USB_FRAME_HISTORY); would have to be used).
Also a lot of compiler warning because of unknown pragmas in the soundplane code and errors in math.h/cmathh (probably because of incompatible macros).
The soundplane code seems to use the pthread library directly also (which isn't available on Windows).

So a Visual Studio build seems not so easy to get working.
Perhaps cygwin would be a more realistic route to get this to compile on Windows?

[TheTechnobear]

Ive not tested cmake files with windows so they probably need some 'adjustments'
juce is not used, probably missing 'defs', and other errors are probably due to the windows compiler differences , as the soundplane code has never been compiled on windows ( ML dont support it yet). which, is also why its got the pthread hardcoded...

the bigger issue, is not building for windows... it is the fact that libusb will not work under windows, due to isosynchronous transfers. this means Id need to write a new driver, probably based on libusbx.
this is also true for the eigenharp, as I do not want to bring in the eigenharp driver (if I can a avoid it) as I don't have the source for it.

so no, cygwin, really is going to make much difference really...
(probably simpler fix, is making SPL an 'optional' compile unit)

all these things are not 'difficult', but not really a priority for me at the moment, my priority for MEC is the small footprint format for rPI/BBB/Bela - macOS/Linux really has been a 'low cost' bi-product, which also makes development easier.
(the build/compile/run cycle is much faster on my mac, than on the BBB :) )

I guess once Ive got MEC complete (please bare in mind, this was not really a 'release'), then I'll consider porting to windows.

if your ultimate aim is to use under rPI/BBB/Bela, but your trying to compile on windows to 'test/dev' (in a similar way Im using macOS), Id suggest perhaps use a lightweight linux vm on windows, its closer to your target platform, its a much nicer dev environment anyway ;)

side note: Im trying to keep the SP code, close to the ML code base for now, so I can inherit new touch tracker code... once this is released, I may let it 'diverge' a bit more.

[NothanUmber]

Just had a look into the libusb FAQ, perhaps there is hope to get at least Windows 8.1/10 support working without writing a new driver: "WinUSB does not support isochronous transfers under Windows XP/Vista/7/8. WinUSB under Windows 8.1 or later supports isochronous transfer. Take note as of now libusb Windows only supports isochronous transfer using the usbdk backend (version 1.0.21 and later)."

Perhaps one in-between step could also be a Windows version without soundplane support (so that code wouldn't have to be ported in the first place).

But for Bela crosscompiling Linux is probably the easier route then (which would also be the primary thing I would be interested in MEC). My main PC is dual boot Linux/Windows anyways and on the Surface I have at least a VM.

Thinking about adding the Morph support to MEC first as it looks simpler that way to reach my main goal (getting Morph-to-MPE conversion working on a BBB board). Will try to keep it encapsulated enough that it can also easily be taken over to HEELP later on though. (Which might be more fun on PC/Mac with it's UI and plugin hosting capabilties - not sure whether it will ever reach the low profile of MEC, so perhaps having the instrument specific code as part of both projects makes sense as a long term solution also).
Will try not to interfere with your code - particularly not not the the SP code. (Think it won't be necessary anyways - e.g. touch detection is already done on the Morph hardware, the API already gets "contact centers". So if you are not interested in the precise shape of the touch thingy and just the x/y/z position then these centers is all you have to care about.
The only thing I wouldn't rule out is that the layout engine might be useful for Soundplane also. Will write this encapsulated from the low level Morph dependent stuff, so if it should be useful for other inputs then this would be an option.

Morph support take some time though. Still don't have any hardware in the first place...

[TheTechnobear]

libusb - yeah, this is what I tried... (win10/libusb/usbdk) but it didnt work.
saying that, Ive just gone back to look at what I tried, and it appeared I used 1.0.20, rather than 1.0.21 - which seems odd, given I was reading the same FAQ as you... and I also have 1.0.21 on my drive!
(perhaps I had some kind of build issue with 1.0.21)
anyway, Ive still got all my test files, so I can give it another go with 1.0.21... which at a minimum will 'refresh my memory' on what the issue was ;)

[TheTechnobear]

ok... so I re-tested it
summary : I was correct it doesn't work ;)

the version 1.0.20 was a red-herring, I was using 1.0.21...
testing with libusb 1.0.21/usbdk (latest version)/windows 10 (vmware)

there are 2 issues... which may be to do with my VM, or not.

so the way I test is to use the low level eigend tools, pezload and pico dump...
using libusb/usbdk, I get the following:

a) if I use pezload on windows to load the firmware, it appears to work... but when I connect picodump, it 'resets' the pico back to its unloaded firmware state.
(this also happens if i use pico dump on the mac, so it appear the firmware is not really loaded correctly)

b) if i load the firmware using pezload on macOs,
then run picodump on windows, then it starts correctly, but then throws errors as soon as it attempts to do the first iso transfer.

(of course if I do the above all on macOS or Linux, it works fine)

it also feels like usbdk, has some 'tracking issues' with devices being repeatedly connected/disconnected, but that may not be an issue if it works correctly.

perhaps it will work on a real windows machine but it all feels a bit flakey (saying that windows driver handling feels flakey at the best of times ;))

if you want to try, then you will find on my eigenD repo a win64testing branch, just check this out, and build it. (its not 64 bit!, its still 32bit, as this was the first hurdle i hit, being 'low in the stack')
apart from this, you will obviously have to install the usbdk driver.
this works, by using a libusb.dll in resources, based on 1.0.21, which I had to build since the default libusb binary for windows does not included usbdk support.

frankly, it all feels a bit unreliable, and I've not even been able to test its performance is acceptable :(

all this 'faffing' required to even to get to this stage, does not really make me feel like continuing with this approach, hence why it felt better to do a driver using a SDK that natively supports iso transfers.
(at least the error handling might be better/more informative)

anyway, im putting it back on the back-burner for when i have a bit more time/enthusiasm for it ;)

[NothanUmber]

Thanks, will give it a try.
Have compiled MEC on Linux in the meantime (which worked without any issues), going through the code now to understand what you do there :)

One thought: Perhaps we could make the "button commands" that I think would be essential for Morph a general MEC mechanism. Essentially these commands allow to set variables from the JSON preferences to other values and can be triggered e.g. by pressing a "button".
Description: https://github.com/NothanUmber/HEELP/blob/master/layouts/morphConfigSyntax.json
Example: https://github.com/NothanUmber/HEELP/blob/master/layouts/Continuano.json

Then you could use either a Morph or a Push to reconfigure any other MEC supported instrument.

[TheTechnobear]

theres not a lot of 'general interaction' at the moment, as you'll see, really its setup to be 'loaded' and forgotten... setting the json vars is one thing, but currently they are only read at 'init' time.

also, currently the mapping for the soundplane is all done in the the soundplane layer, and is closely associated with the touch tracker. (this mapping provides many of the things you are putting in your layout files) , I guess, I could make it just return an x/y/z, then doing the mapping using layout, but not sure it buys me much... but i guess if the codes there, no harm either :)

one thing, I'm a bit wary of, if the mapping is very complex, this could start having performance implications... also there is a question about where 'surface mapping' stops and mapping in the the 'sound engine' starts. (e.g. ranges)

personally, Id start with something simple, and then start to evolve it, as you find out how you want to use it.

note: Ive still yet to work out what Im going to do with MEC/HEELP/EigenD in 2017, theres obviously pros/cons for them all, and Ive only limited time to work with them, so Im going to have to prioritise.

[NothanUmber]

ok, understood. Will try to build the Morph code in a way that it can later on be reconfigured by rereading the preferences but will implement the actual mechanism in a second step. My main goal is actually to have support for the "Continuano layout" which already needs quite a number of tricks (like irregular sized cells, diatonic, chromatic and no pitch rounding etc. The other things like 4th-grid (Linnstrument-like) or just xyz-plane (Continuum-like) would just be by-products.

But perhaps I could start with a hardcoded xyz-plane to test out grounds - that would be easier for sure.

Regarding uncertainties: Yeah, many options :)
Integrating the Morph code into EigenD would actually also be an option. But first I want to get something running - and for that MEC looks like the most inviting playground. (Initially I planned to create a playground application from scratch - but at least atm. I don't see a major disadvantage with starting from the MEC sources - and being able to plug in either an Eigenharp or a Morph into the same "flash once and foget" BBB box sounds appealing!)
For HEELP I currently still have a wait-and-see stance The main benefit compared to EigenD should be simplicity to extend it and be less prone to race conditions (which are imho time consuming to trace down in EigenD). Not sure yet about the simplicity aspect considering the multithreading/multiprocess approach and the benefit to my main use case this would buy... But we'll see.

[NothanUmber]

Ok, tried the win64testing branch on a real Win10 machine, am unhappy to report that EigenD just crashes as soon as I try to load a Pico setup (e.g. the standard setup). This happens no matter whether I have the UsbDk driver installed or uninstalled.
Getting a nullpointer exception in pic_usb_win32.cpp, line 1185: ssize_t cnt = libusb_get_device_list(usbcontext_, &devs);

Edit: Have been using this usb´dk driver: v1.00-15, x64

[TheTechnobear]

dont try eigenD (there may be other issues!?), try pezload and picodump... these dont crash for me.
(yeah, Im using the same usb dk driver)

[NothanUmber]

looks good on first sight:

d:\dev\git\EigenD\tmp\bin>pezload
using version 5 of firmware
log:pic::usbenumerator_t::enumerate : seaerching V 8505 P 1
log:pic::usbenumerator_t::enumerate details : V 32903 P 36 B 1 A 2
log:pic::usbenumerator_t::enumerate details : V 32903 P 36 B 1 A 2
log:pic::usbenumerator_t::enumerate details : V 1103 P 45322 B 4 A 4
log:pic::usbenumerator_t::enumerate details : V 1103 P 45322 B 4 A 5
log:pic::usbenumerator_t::enumerate details : V 1060 P 16327 B 5 A 6
log:pic::usbenumerator_t::enumerate details : V 8505 P 1 B 5 A 7
log:pic::usbenumerator_t::enumerate found : 2139.0001.0007.0005
downloading to 2139.0001.0007.0005
log:pic::usbdevice_t::usbdevice_t usb device create 2139.0001.0007.0005 iface 0
log:pic::usbdevice_t::impl_t::open_usb_device 2139.0001.0007.0005
log:pic::usbdevice_t::impl_t::open_usb_device: trying device 8087.0024.0002.0001

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 8087.0024.0002.0001

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 044f.b10a.0004.0004

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 044f.b10a.0005.0004

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 0424.3fc7.0006.0005

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 2139.0001.0007.0005

log:pic::usbdevice_t::impl_t::open_usb_device: found device 2139.0001.0007.0005
log:pic::usbdevice_t::impl_t::open_usb_device: opened device 2139.0001.0007.0005

log:usbdevice opened low speed
log:usbdevice opened successfully
log:usbdevice_t::impl_t::detach() : detaching client
log:usbdevice_t::impl_t::detach() : done detaching client
log:pic::usbenumerator_t::enumerate details : V 1133 P 49971 B 6 A 2
log:pic::usbenumerator_t::enumerate details : V 1118 P 654 B 6 A 3
log:pic::usbenumerator_t::enumerate details : V 1133 P 49225 B 6 A 4
log:pic::usbenumerator_t::enumerate details : V 8457 P 1809 B 6 A 5
log:pic::usbenumerator_t::enumerate details : V 1410 P 9 B 6 A 7
log:pic::usbenumerator_t::enumerate details : V 2821 P 6044 B 6 A 8

d:\dev\git\EigenD\tmp\bin>picodump
log:pic::usbenumerator_t::enumerate : seaerching V 8505 P 257
log:pic::usbenumerator_t::enumerate details : V 32903 P 36 B 1 A 2
log:pic::usbenumerator_t::enumerate details : V 32903 P 36 B 1 A 2
log:pic::usbenumerator_t::enumerate details : V 1103 P 45322 B 4 A 4
log:pic::usbenumerator_t::enumerate details : V 1103 P 45322 B 4 A 5
log:pic::usbenumerator_t::enumerate details : V 1060 P 16327 B 5 A 6
log:pic::usbenumerator_t::enumerate details : V 8505 P 257 B 5 A 7
log:pic::usbenumerator_t::enumerate found : 2139.0101.0007.0005
log:pic::usbenumerator_t::enumerate details : V 1133 P 49971 B 6 A 2
log:pic::usbenumerator_t::enumerate details : V 1118 P 654 B 6 A 3
log:pic::usbenumerator_t::enumerate details : V 1133 P 49225 B 6 A 4
log:pic::usbenumerator_t::enumerate details : V 8457 P 1809 B 6 A 5
log:pic::usbenumerator_t::enumerate details : V 1410 P 9 B 6 A 7
log:pic::usbenumerator_t::enumerate details : V 2821 P 6044 B 6 A 8
log:pic::usbdevice_t::usbdevice_t usb device create 2139.0101.0007.0005 iface 0
log:pic::usbdevice_t::impl_t::open_usb_device 2139.0101.0007.0005
log:pic::usbdevice_t::impl_t::open_usb_device: trying device 8087.0024.0002.0001

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 8087.0024.0002.0001

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 044f.b10a.0004.0004

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 044f.b10a.0005.0004

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 0424.3fc7.0006.0005

log:pic::usbdevice_t::impl_t::open_usb_device: trying device 2139.0101.0007.0005

log:pic::usbdevice_t::impl_t::open_usb_device: found device 2139.0101.0007.0005
log:pic::usbdevice_t::impl_t::open_usb_device: opened device 2139.0101.0007.0005

log:usbdevice opened low speed
log:usbdevice opened successfully
log:pic::usbdevice_t::usbpipe_in_t::impl_t 130
log:loading calibration from device
log:loading calibration done
log:restoring led mask:255
log:usbpipe_in_t::start()
log:usbdevice_t::impl_t::start_pipes() : pipes started!
key: 00 c1:1552, c2:0948, c3:2174, c4:1760
key: 00 c1:1552, c2:0946, c3:2174, c4:1762
key: 00 c1:1552, c2:0948, c3:2174, c4:1762
key: 00 c1:1552, c2:0948, c3:2176, c4:1762
key: 00 c1:1554, c2:0946, c3:2174, c4:1762
key: 00 c1:1552, c2:0946, c3:2176, c4:1762
key: 00 c1:1552, c2:0948, c3:2174, c4:1762
key: 00 c1:1554, c2:0948, c3:2174, c4:1760
key: 00 c1:1554, c2:0946, c3:2174, c4:1762
key: 00 c1:1552, c2:0946, c3:2176, c4:1762

I also get changing key values when wiggling the keys on the Pico.

Perhaps the VM is messing too much with the timing?

[TheTechnobear]

ok, thats promising
Id guess something in the win10 vm drivers (as the same vm running linux works fine), Im not entirely surprised, as I mentioned before the Eigenharp driver is not working either.
(though Im sure it was previously, but that would have been prior to win10... I think win7/8?)

takes me back to where I was (and what I said on G+ a while back) , I really need to get a real windows machine to take this further.... so I can fix the remaining issues, and get a 64 build going.
... though at least now we now know, this is probably a fairly trivial task, not much different from what Ive been doing with macOS/Linux.

[NothanUmber]

I can recommend the Surface 4 Pro or the new Dell XPS 15 (not listed yet, one of the last machines with exchangeable battery - would buy that if I were in the market for a new notebook) or the Dell XPS 13 2in1/normal. But those would probably only make sense if you see utility besides EigenD compiling/testing for them price-wise :)
Looked for cheap options with at least 4 GB RAM, that would also have some use outside the EigenD compile/test world:

• The Udoo x86 boards (compact Arduino compatible maker boards)
• Asus T101HA-GR031T Transformer Book (tablet with attachable keyboard)
• search on eBay for used machines. Found a lot of very nice PCs and notebooks for < 250 Euro
  If you allow it, the Eigenharp community would buy you one of those (or pay a share of a more expensive machine) :)

edit: well, and then there would be Bootcamp. Don't have experience with this, but I know a number of Sonar users are using it on their Macs and are happy with the results.

[TheTechnobear]

@NothanUmber , Ive moved your comments re BBB/Bela to a new 'issue'
see #2

[TheTechnobear]

Ive added comments to docs/todo.md

basically for windows, there are 2 stages
step 1
MinGW build , which can utilise pthreads
I think from apart from small changes to reflect windows build in cmake, it should basically build.
(everything else should be crossplatform .. note eigenharps will by default need eigenharp driver)
... sub projects (e.g. mec-vst) might need small changes, e.g. jucer.

step 2
get rid of mingw/pthreads requirement.
I think main issue here is rtmidi, which uses pthreads.
the natural replacement is probably JUCE, but I need to ensure this doesnt compromise the 'lightweight' nature of the project. but I think Ive a way to do this :)

other things I need to check are locations of resource files, I think should be ok, just needs testing.