Pico not connecting?

Eigenharp
1

Thanks for your replies. However, I am still unable to get this working.

Here’s what I have tried:

  • Set audio output to my audio interface (confirming this works by patching an oscillator to the output)
  • Connecting Pico to my computer using both a hub and directly
  • Tried 2 different USB cables
  • Tried a different computer

At this point I’m just looking for any visual feedback on the Pico. Am I correct that a simple test patch of the Eigenharp module + LFO module (no audio module) with the LFO patched to any of the LED inputs should make the LEDs on the Pico flash?

1 Like
2

@t_byrd Here is ONLY a light pattern (p-snake) some green an red LED will light up, so you can test.
(sorry out of studio - in a hurry- not much comments)
Pico-p-snake pattern.vcv (898 Bytes)

1 Like
3

Thanks for the quick reply! Still nothing :confused:
Tried this patch with both computers and different cables/hubs etc.
Should there be voltages displayed when I hover my mouse over the connections in your patch? Everything shows 0V.

1 Like
4

Yes thats correct, and it should be ONLY lights as I write above.

1 Like
5

System Information : what does it show in USB?

here is mine
Screenshot 2024-02-17 at 15.25.53

2 Likes
6

Does EigenD work when having the Pico connected to the same USB-port?

1 Like
7

mod note: moved to a new topic

ok… so, if you have the Eigenharp module with an empty patch OR with audio module and audio interface set. then touching a key you will see ‘activity’ on the MAIN led in vcv.
also if you have loaded the 1-simple tutorial patch the top most led should light green - as its the start of the scale. (assuming AUDIO module is set)

( you can see this in my video)

if it doesn’t I suspect the issue is more likely hardware related.

as @keymanpal says, first thing to do is look at the USB system information and see if the computer is seeing the pico, and also if the firmware is loading.

it’ll have product id 0x0001 before firmware is loaded, then switch to 0x101 on loading. (iirc)

have you had this pico working before on these computers?
if you are using an M2 Mac… what adapter/hub are you using to convert from usb-c to usb-a? have you used this with the pico before (successfully)

unfortunately, as I mentioned in my troubleshooting guide… the pico is very temperamental with usb cables/ports etc… many newcomers have issues (including with EigenD)

we have been testing on M1/M2 Macs, and using macOS up to the latest (Sonoma 14.2.1) so its doubtful its an os/Mac issue.

to be clear, EigenD is not required… and will not help, I’d only test with EigenD IF you have it already installed.

my m2 laptop running Sonoma has never had EigenD installed on it, and works perfectly :wink:

as for ‘more information’… IF you can see the usb device

you can start VCV Rack from the command line (aka Terminal), then when you add the Eigenharp module a LOT of messages will appear in the terminal window, which’ll indicate any issues.
however, I highly doubt, the usb device is present … in which case you get nothing much, since the application cannot see the pico due to a ‘faulty’ usb connection.

2 Likes
8

Screenshot 2024-02-17 at 5.49.32 PM
Screenshot 2024-02-17 at 5.49.32 PM725×568 27.2 KB

Bit of progress, this is how it’s showing up in my USB devices. No change when I run VCV rack with the Eigen modules.

I have never used the Pico with either computer, it’s been sitting on my friend’s shelf for years unused.

1 Like
9

I have a small non-powered USB C to USB A hub that I use to have USB-A ports on the M2 Mac. This didn’t work with the Pico by itself though. Then I attached the Pico to a powered USB-A hub (and just used the previous hub as USB-C to USB-A adapter as this particular powered hub has no USB-C ports) - this worked. So, might be worth to try another (powered) USB hub.
On the old Intel Macbook it works to directly attach the Pico to an internal USB-A-port of the notebook…

1 Like
10

that’s not a pico…
as Antonio showed earlier Eigenlabs vendor id is 0x2319 and the product id for the pico is either 0x101 or 0x001

EDIT: ok… this gets weird…

as above, this is NOT the vendor id, nor product id that a pico should have.

BUT digging around the Eigenlabs code a bit, it appears to be the code a pre-production/prototype used to have.
more specifically, I think its probably the vendor id/product id f the chipset that used inside the pico.
SO… this was what was present during early development before it had its own firmware and so vendor/product id.

is this possibly a ‘pico’ that is pre-production/development?

if not, I wonder if the issue is if this pico is somehow ‘damage’ and lost its boot loader, and so has now revert to the chipset manufactures boot loader.

unfortunately, really there’s not a huge amount I can say outside of this…
Ive never seen this before, and Im not sure what ‘state’ this device is in.

2 Likes
11

Hi again. Sorry for the late reply, I got busy with a few other things.

So my friend who is the original owner of the Pico worked at Eigenlabs. I think he got his unit before they were officially released and it sat on the shelf without ever being used. So that should explain the vendor ID mismatch.

We’d like to get this Pico running with Meta Morph eventually, but no rush at the moment. I don’t think this vendor ID issue applies to many units so no need to discuss this further here.

Thanks for all the troubleshooting help!

1 Like
12

unfortunately, I’m not sure I can support this… I’ve no idea if the firmware thats uploaded to the pico is the same/compatible , or if there are any other quirks/oddities.

the Meta Morph and EigenLite software (that meta morph is built on) is open source, so you could attempt to modify it, and see if you can get it working.
basically try EigenLite tests first, as if that doesn’t work… then Meta Morph definitely wouldn’t either…

also given the circumstances it may be worth trying EigenD… see if they left in support for it, and if it does how does it ‘appear’ in workbench. that might give some clues to the nature of this pico.
( I fear if they did ‘remove’ the support, then there was probably a reason)

one of the issues is, there is also a so called ‘micro’ eigenharp mentioned in the code, which Ive always assumed was a pico prototype, but is rather different… has quite a bit different code.
and Ive no idea if your pico, is related to that… or the released pico… or something in between.
… we just have no info.

thats why it’d be a nightmare trying to troubleshoot / support something that we have zero experience with… and really dont know ‘what’ it is precisely.
(as you can see from the posts already on this topic )

2 Likes
13

John showed us that “Micro” at the first Eigenlabs conference. It was not just a Pico with a prototype firmware but a separate model that was never mass-produced. It was as far as I remember just a 2x4 (or 4x4, not sure anymore) grid of keys without breath-pipe, ribbon and I think not even mod-keys. The minimal imaginable Eigenharp, mainly for devs to have it on the side of the keyboard while coding and testing.

3 Likes
14

Interesting, no pictures?!

It makes sense they’d start with something that was essentially just the keys , as this is where most dev effort is focused.
( in fact I’d not be surprised if this was used as part of alpha’s development to refine the ‘key’ code)

All that said, when the manufacture/product is left as the native chip manufacturer, then we know the bootloader is different from released version …
It could just be ids, but could be more.

The odd bit here is eigenlabs would already have had the manufacture id, as the alpha was already in production…. So no reason for them not to use it, unless this pico predates even the alpha release.

But yeah all speculation, as we know solid information on dev process and prototype models.

1 Like