I have uploaded circuitpython adafruit sample usb midi controller code on the new Pi Pico microcontroller. The device is detected as midi device on Windows and Mac OSX and sends midi notes to Kontakt player. When connected to Samplerbox 2019 image as midi synth, there is no sound output.
How to debug and solve this issue?
Hello rajivdeo,
First to verify I understand correctly: you connect the PiPico with its USB to samplerbox. Because of the circuitpython package it should be recognized as a midi device.
Does it derive its power from that same usb interface (=from samplerbox) ?
If my understanding is correct, then thanks for this interesting tip!
Now for your question:
- Please use the latest=20200810 image from the Downloads page
- Debugging is explained in debugging paragraph on the Build page
- It may also be useful to download renewed midimon.py in the download area.
The console log of samplerbox start and/or midimon output should give some leads.
Regards, Hans
Hello rajivdeo,
I can't comment on the failing new distribution without more info, except for: take a close look at the files on /boot (or root dir of inserted SD on PC). There may be configs on there (config.txt and samplerbox/configuration.txt) you may have adapted to your local setup which are replaced by the originals now.
Anyway, this seems not to be related with your main subject of using the pico.
The USB conflict / double usage is indeed a likely cause. I have to think about that...
Additional question: where do you store your samples
- On the internal sample space
- On a USB drive not recognized anymore when using the pico
Thanks, Hans
Hi rajivdeo,
Upcoming release will support mutually exclusive use of USB storage: if the usb-storage contains a valid samplefolder entry, this device is used. Otherwise the internal sample space is used. This enables your usage; also in my opinion the most straightforward way.
But if the existing samplerfolder(s) contain(s) no valid sample sets, this will remain the preferred device:
- You can repair an erroneous definition.txt via the webgui
- Switching to the internal sample space will result in the wrong sounds, which is also frustrating and could even cause extra confusion
Regarding the "new user frustration": there is an extensive FAQ on "I get no sound", which starts with suggestion to test without USB.
It's a DIY product, one should read the docs. I understand the full docs are intimidating, therefore I added a quick start with FAQ for newbies to have an easier start. But if a newbie doesn't even want to open a FAQ, he/she should not choose a DIY product.
Mind the term "newbie" is not meant in a disqualifying tone, everybody needs to start.
I am a hobbyist sharing my code for free so I don't have "users", but only fellow hobbyists (which surely includes motivated newbies - their feedback has proved to be very helpful / inspiring many times).
Side note: Those wanting to use a thumb or other usb storage device can build a serial midi out on the midi controller and power feed the controller in an alternative way (could even be PI-pins).
This also opens a development direction of having the samplerbox-PI combined with a Pico / Arduino / ESP midi controller to add all controls for samplerbox in the same enclosure. This way the need for a complex=expensive keyboard with lots of (programmable) knobs / buttons / sliders isn't necessary anymore.
Very inspiring, so thanks for bringing up this subject!
Hi Rajiv,
I managed to ignore the boot issue, sorry for that.
When direct attaching screen & keyboard, don't you see any boot activity?
Or do you mean that the device boots, but samplerbox process is not started properly - thus seaming "dead"?
In my opinion, if starting OK on 2019 then on 2020 it should at least show boot activity on system console on which you also should be able to logon. This is because the difference between these two release on OS level (the level where you boot) is actually very small. An rpi-update has been done, but this should only improve compatibility (instead of reducing it as you observe).
And if you can logon, you can also do debugging as mentioned on the build page.
I tend to think that one of application level features (a lot were added) or some typical part of your setup, causes samplerbox function to fail on PI-zero.
I'm puzzled by your observation, as the 2020 dist is used by many others and except for "normal" installation at particular setups, it works out-of-the-box. I have to add you are the only one I know of using my dist with PI-zero.
Hi Rajiv,
Thanks, I like exchanging ideas.
Regarding the PiZero, concluding the issue is solved by agreeing that the 2020 image is incompatible is unsatisfying for next reasons:
- the OS is the same (dedicated setup based on debian Jessie).
I may have done and rpi-update - but this should enlarge compatibility instead of reducing it.
- The hardware should not react on application changes.
- I accept "it doesn't work", but can't understand "it doesn't boot".
I'd sure would like to know what startup messages say when powering on with screen & keyboard attached (if possible).
I suspect the PI is started and perhaps you can even logon via network, if enabled in your case, so the direct screen/keyboard isn't even necessary.
There is no apparent reason why the 2020 image should have become incompatible, leading to a more alarming statement: no reason to think next image should be compatible again as it's a next application change on the same outdated Jessie base - leaving you empty handed again. Hmm.
I am working on a less limited, buster based, image in order to support PI-4 (got the prototype working) and others like PiZero (when I started I wasn't aware of anybody using the zero already). But I expect the distributable version will take several months, realistic before yearend earliest.
If you want work with Pico and 2019 release, you can apply the patch yourself: around line 940 in samplerbox.py replace
Code:
gv.samplesdir = SAMPLES_ONUSB if os.listdir(SAMPLES_ONUSB) else SAMPLES_INBOX # use builtin folder (containing 0 Saw) if no user media containing samples has been found
#gv.basename = next((f for f in os.listdir(gv.samplesdir) if f.startswith("%d " % gv.PRESET)), None) # or next(glob.iglob("blah*"), None)
with
Code:
gv.samplesdir = gv.SAMPLES_INBOX
try:
if os.listdir(gv.SAMPLES_ONUSB):
for f in os.listdir(gv.SAMPLES_ONUSB):
if re.match(r'[0-9]* .*', f):
if os.path.isdir(os.path.join(gv.SAMPLES_ONUSB,f)):
gv.samplesdir = gv.SAMPLES_ONUSB
break
if gv.samplesdir == gv.SAMPLES_INBOX:
print ("USB device on %s has no samplesets, using SD space on %s" %(gv.SAMPLES_ONUSB, gv.SAMPLES_INBOX) )
except:
print ("Error reading USB device mounted on %s" %gv.SAMPLES_ONUSB)
If you copy/paste the code, the confusing line wrapping is gone...
Hope this helps,
Hans