ilmenator
-
Posts
2,302 -
Joined
-
Last visited
-
Days Won
37
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by ilmenator
-
-
Hi,
I am getting a message about a Timeout on port 0x21 quite regularly. I am not sure whether this actually is a problem (I haven't noticed any so far), but it bothers me and I'd like to know what this is. Here is an example of what I get in MIOS Studio:
[267727.006] Init DHCP [267728.076] SD Card connected: [267728.796] Init DHCP [267728.797] [MBNG_FILE_C] Event Pool Number of Items: 396 [267728.797] [MBNG_FILE_C] Event Pool Allocation: 15867 of 65536 bytes (24%) [267728.801] [MBNG_FILE_L] DEFAULT.NGL hasn't been changed; reading labels from existing DEFAULT.BIN file. [267728.802] [MBNG_FILE_L] 15 labels found in /DEFAULT.BIN file [267728.803] [MBNG_FILE_S] snapshot #0 not stored in /DEFAULT.NGS yet [267749.392] [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 [267761.075] [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 [267768.483] [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 [267773.455] [FILE] Download of 39392 bytes in progress (0%) [267773.601] [FILE] Download of 39392 bytes in progress (25%) [267773.748] [FILE] Download of 39392 bytes in progress (51%) [267773.894] [FILE] Download of 39392 bytes in progress (77%) [267774.018] [FILE] Download of 39392 bytes finished. [267775.023] [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21 [267800.299] set debug off [267800.301] Debug mode turned off [267801.305] [MIOS32_MIDI_Receive_Handler] Timeout on port 0x21About two weeks ago, on the very same hardware, this Timeout message wasn't there. Any clues about what's going on here? Which port is 0x21?
-
12 hours ago, btrd72 said:
RN common pins were missing a 5V feed.
Sounds like floating RN common pins to me.
-
Custom mainboard holds the usual stuff plus a complete DIO_MATRIX for keyboard scanning and parts of an AINSER64 (MCP3208 and the 595). From there, MUXA...MUXC as well as CH0...CH7 signals go to the frontpanel. MIDI I/Os are also on the mainboard.
-
I was going to wait until the MIDIbox NG part of this was a little more mature, but you already spotted this over at the MI forum... So, this is a dedicated user interface / controller for the Mutabel Instruments Ambika analog synth, housed in a recycled synth case from the early 90's. The black PCBs are the six voice cards of the Ambika.
-
1
-
-
Yes you can - simply click "edit" in your first post and then add [solved] to the title.
-
If the buyer should need the BLM PCB, just drop me a PM... I have a few left from the last v2 batch.
-
All the schematics are known, so you could easily design your own board layout.
-
Mal ehrlich: wen interessieren Kratzer im Langloch? Da ist mir eine sichere Befestigung des Gerätes doch wichtiger...
-
On 27.3.2017 at 11:28 AM, u-link said:
Thanks again for the pointer sisters.
Not sure everyone can remember them (and understand that joke
), here is a pointer...
-
That is just their business model, and it is perfectly understandable not to want to deal with consumer electronics issues. They are probably not a very large company and having to produce (and pay for the production) up-front could break their back, financially.
-
Nylonunterlegscheiben, werden teilweise mit den Rackschrauben mitgeliefert, sind aber viel preiswerter und auch einzeln im Eisenwarenhandel zu finden.
-
Sounds like a faulty resistor R8 or R10, or wrong value installed? Unpower the unit and measure resistance across R8 and then R10, both should read 220 Ohms.
If that doesn't help, check resistance between M- on J6 of the MIDI IO board and pin PC12 on the STM32F4 board - this should also be 220 Ohms.
These errors are a pain to find the root for, but it's better than having to search for an error that only shows every now and then...
-
Have you tried earlier revs (i.e. before 092)? If you find that earlier versions work, then it sure is a software bug.
I remember that some MIDI outs that are based on 3.3V are problematic with some MIDI gear that expects the "regular" 5V sources (this seems to be an issue even though MIDI is essentially a current loop). Maybe there are some tolerances between the Outs on your board that you hit?
-
Here is the solution to the problem: by changing
rows=8into
rows=10the notes output for each of the 37 keys is correct, not just for the first 32.
-
1 hour ago, thumper said:
I tried to attach them to the post but it came up with an error. Maybe the files are too big?
That's right, file size is the problem here.
-
No, the trouble was that the images were too large. I had to reduce them in size to get them below the maximum file size :-).
-
On 29.1.2017 at 7:08 PM, jaytee said:
Here are photos of my single-supply wiring.
Just because off-site documentation tends to get lost over the years: here are the images.
-
The Evolver is a great synth - it's a pity the Poly Rack is not available anymore (actually, that saves me quite some trouble at home...)
-
1
-
-
Well thanks anyways! I might as well need to analyse the current patch status and interpret a SysEx stream from the target machine, so I'll probably have to set the LED status manually in any case at a later time.
-
Hi Zam,
thanks, that actually does the trick after uploading the new .NGC: then, the LEDs are lit correctly. However, after power cycling the box or sending a reset command via the command line, this is not the case and all LEDs are off, no matter whether the LED event definition is coming before or after the corresponding button or sender definition(s). Have you solved this for your box, or are you still working on this problem?
Best, ilmenator
-
Yes, this will be the next step, but it is getting more complex than just that: the external messages are different, i.e. the machine I am trying to control is accepting the CCs as above, but is sending out NRPNs and Data (CC#6, CC#38) messages instead... and, these are not spanning the whole range from 0 to 127. I'll see if I can also just send back the same messages (NRPN and DATA) to control it.
One more thing I would like to fix is that upon a power cycle, the initial value is set correctly to 2, but the corresponding LED is not lit (none of the LEDs shines). Also, after the upload of a new .NGC file version, the LED status remains, even though the value has been reset to 2. It takes a button press first to "synchronize" the LEDs. How could I get the LEDs right from the start?
Best, ilmenator
-
That's right, I've been trying to find the service notes for this keybed (Roland Pro-E) for over a year now, but it seems this machine is so uncool that noone bothers...
-
I am still trying to figure out why I get the same note events when pressing different keys (with reportedly different make contacts, as in the debug report above). Any clues on how this could be cured?
Thanks, ilmenator
-
10 hours ago, Zam said:
I just have another idea without NGR but radio_group for led
not sure it will work but it deserve a try
Hi Zam,
thanks a lot for this hint - it actually works quite nicely, here is the complete code in case anyone wants to adopt this:
MAP1 2 26 52 76 102 125 # EVENTs EVENT_BUTTON hw_id=25 fwd_id=sender:1 range=MAP1 value=2 button_mode=toggle EVENT_SENDER hw_id=1 id=100 type=CC CC=103 ports=10000100000000000000 #to send out the CC EVENT_SENDER hw_id=1 id=101 fwd_id=sender:3 if_equal=2 radio_group=1 #UP EVENT_SENDER hw_id=3 id=301 fwd_id=led:17:127 EVENT_SENDER hw_id=3 id=302 fwd_id=led:18:0 EVENT_SENDER hw_id=3 id=303 fwd_id=led:19:0 EVENT_SENDER hw_id=3 id=304 fwd_id=led:20:0 EVENT_SENDER hw_id=3 id=303 fwd_id=led:21:0 EVENT_SENDER hw_id=1 id=102 fwd_id=sender:4 if_equal=26 radio_group=1 #DOWN EVENT_SENDER hw_id=4 id=401 fwd_id=led:17:0 EVENT_SENDER hw_id=4 id=402 fwd_id=led:18:127 EVENT_SENDER hw_id=4 id=403 fwd_id=led:19:0 EVENT_SENDER hw_id=4 id=404 fwd_id=led:20:0 EVENT_SENDER hw_id=4 id=405 fwd_id=led:21:0 EVENT_SENDER hw_id=1 id=103 fwd_id=sender:2 if_equal=52 radio_group=1 #UP&DOWN EVENT_SENDER hw_id=2 id=201 fwd_id=led:17:127 EVENT_SENDER hw_id=2 id=202 fwd_id=led:18:127 EVENT_SENDER hw_id=2 id=203 fwd_id=led:19:0 EVENT_SENDER hw_id=2 id=204 fwd_id=led:20:0 EVENT_SENDER hw_id=2 id=205 fwd_id=led:21:0 EVENT_SENDER hw_id=1 id=104 fwd_id=sender:5 if_equal=76 radio_group=1 #RANDOM EVENT_SENDER hw_id=5 id=501 fwd_id=led:17:0 EVENT_SENDER hw_id=5 id=502 fwd_id=led:18:0 EVENT_SENDER hw_id=5 id=503 fwd_id=led:19:127 EVENT_SENDER hw_id=5 id=504 fwd_id=led:20:0 EVENT_SENDER hw_id=5 id=505 fwd_id=led:21:0 EVENT_SENDER hw_id=1 id=105 fwd_id=sender:6 if_equal=102 radio_group=1 #PLAYED EVENT_SENDER hw_id=6 id=601 fwd_id=led:17:0 EVENT_SENDER hw_id=6 id=602 fwd_id=led:18:0 EVENT_SENDER hw_id=6 id=603 fwd_id=led:19:0 EVENT_SENDER hw_id=6 id=604 fwd_id=led:20:127 EVENT_SENDER hw_id=6 id=605 fwd_id=led:21:0 EVENT_SENDER hw_id=1 id=106 fwd_id=sender:7 if_equal=125 radio_group=1 #CHORD EVENT_SENDER hw_id=7 id=701 fwd_id=led:17:0 EVENT_SENDER hw_id=7 id=702 fwd_id=led:18:0 EVENT_SENDER hw_id=7 id=703 fwd_id=led:19:0 EVENT_SENDER hw_id=7 id=704 fwd_id=led:20:0 EVENT_SENDER hw_id=7 id=705 fwd_id=led:21:127Thanks again, ilmenator
Timeout on Port 0x21
in Testing/Troubleshooting
Posted · Edited by ilmenator
Thanks Peter,
not using Windows, I'm on a Mac (Yosemite v 10.10.5)...
It's actually becoming a problem now: I am losing contact with the core, so that for example write operations to the SD card via the MIOS file browser will fail more often than not. This is very annoying as it keeps me from updating my NG configuration file and I can't continue the development of the TSFKAA MBNG setup.