FantomXR
-
Posts
1,035 -
Joined
-
Last visited
-
Days Won
22
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by FantomXR
-
-
Hey people,
I was looking for a way to detect, if an encoder (with metal shaft of course) is touched. Since NG itself doesn't support such touchsensors I was searching for an IC. And I found it:
https://www.mouser.de/ProductDetail/Microchip-Technology/AT42QT1010-TSHR?qs=xbJoyvfFV%2F%252BFK88JVR2efg%3D%3DI've added a 22nF cap between SNS and SNSK and put a 10k resistor right before the encoder. It works great! As soon as I touch the encoder, the "OUT" goes high and if I release it it goes back low.
You just have to connect that to an inputpin of an HC165 and you are done.
Best,
Chris-
1
-
-
6 minutes ago, latigid on said:
Is there a specific problem you are trying to solve?
I guess that routing is way more comfortable and even better if I place all SRs on one PCB next to each other and use pinheader to connect the buttons & LEDs to it directly. For some I reason I never did it like this...
I never had performance problems anyway... so I'm just interested how it is done in the professional world...
-
I know this is an old thread. But my question fits into this topic I think.
What is the "professional" way to place the shift registers? Is it better to place them near the MCU to keep SPI-traces as short as possible or is it better to place them near the objects, that are connected to it (resp. buttons or LEDs)?
I already designed tons of PCBs and I used to put the SRs near the objects which are connected to the SRs. But meanwhile I don't see really much sense in it. It means a lot routing and starting from scratch with any new PCB.
How do you do it?
-
Hey people,
Maybe you can guide me in the right direction.
In my projects I use buttons with integrated LEDs. But I want to get away from the standard HC595. Mainly because it takes a lot of PCB space and it has a lot traces due to the SPI protocol.
Is there another style to control those LEDs? I also work a lot with WS2812. This is great because there is only one single data line from one to the next.
Thanks,
Chris
-
But anyway I'm highly interested what causes this issue... Something seems to disturb the STM when booting... I have no idea.
-
I mean the bootloader of the midibox and not the computer.
-
I remember that I encountered that a few times too already. All digital signals where inverted after system boot. So also buttons that were connected to the midibox didn't sent 127 when pressed but 0 and the keyboard did the same.
I never solved this. Maybe @TK. has an idea.
Did you try to set fastboot on in the bootloader? I think that was my workaround...
-
You can not set the resolution on a "per input" base. So yes, you'd need a dedicated AINSER module.
Please note: MIOS32 only supports two AINSER modules. Although TK shows how to implement a third module in another thread, I was not able to get it running.
-
-
Depending on what you want to do you can leave it away completely.
What housing do you need? DIP or SMD?
-
Well, I hope that it looks better. Now you can really watch the OLEDs build up their text. If this could be speeded up, it would be great.
BTW: I send SysEx strings on the displays.
-
I can confirm Brunos changes work well! :-)
-
1
-
-
Hey people,
my setup contains nine 128x64pixel OLEDs in a horizontal layout. I usually print to all of them at the same time.
Now, MIOS writes to the displays character by character. So it starts with the first line on the first OLED, goes all the way to the first line of the 9th display and then starts over at the 2nd line of the first display.
Since there is a lot of data, it takes time to print to the OLEDs and you really can see how the characters are printed line by line.
So my question is: Is there a way to speed up that transfer rate? I googled a bit and found this on an arduino forum:
https://forum.arduino.cc/index.php?topic=286837.0Is it possible to somehow adapt this to MIDIbox? Do you have an idea?
Thanks,
Chris -
I think I ran into this problem also a while ago. Unfortunately I don't have a fix for that issue.
-
Same here. But it seems to be correct. I've used it a lot already.
-
If you set type=cc then it's logical that it only allows values between 0-127. If you want to send highres-midi you have to set the type=pitchbend or type=NRPN.
If you substract 7682 from 8192 you will get 510, which is almost what you set with the range. In this case you have to use MAPs instead of standard ranges. Then it will work. Please refer to the NGC-manual. For testing purposed I'd recommend not to use ranges anyway.
-
This should totally be possible. Would you please post the related parts of your NGC file?
-
@latigid on as this might effect the programma too, maybe you can answer this question:
Is there any other way to achieve this?
-
23 hours ago, latigid on said:
IMO just wait for ProgrammA v2, it will be awesome :).
Any idea when this will be ready?
-
As far as I know the maximum allowed number of banks is 127. So this shouldn't be a problem.
You want 33 OLEDs? This is definitely nothing easy to do. You need to take care of the clock pin when doing the PCB layout. Nothing you can do on breadboard. Also you'd need a separate power supply for it.
-
Hey TK.,
I wonder why RECEIVERS do not react to banks.
This is the example code:
EVENT_RECEIVER id=1 type=SysEX stream="0xf0 0x33 0x22 0x33 0x00 ^txt 0xf7" lcd_pos=1:1:1 bank=1 EVENT_RECEIVER id=2 type=SysEX stream="0xf0 0x33 0x22 0x33 0x00 ^txt 0xf7" lcd_pos=2:1:1 bank=2I'd expect: When bank 1 is selected the text will be displayed on the first screen. When bank 2 is selected it will show up on the second display. If bank 3 is selected nothing should happen.
But what happens is that it always shows up on both displays. Should it be like this?
In my setup I send a bunch of SysEx strings to the midibox and I'd like to switch between them with banks. Is that possible?
Thanks,
Chris -
43 minutes ago, tago said:
Are 8 SRs in use because the DIO module is configured as a matrix for keyboard scanning?
I don't see the reason why TK choosed sr=9 as emulated shiftregister. But anyway: When working with emulated elements (same is valid for button- & LED-matrices f.e.) it's always good to use a value that is definitely not blocked by real hardware.
The keyboard blocks the first two digital input-SRs (usually HC165) and the first two digital output-SRs (usually HC595).
dout_sr1=1 means the first HC595 in the digital chain. din_sr1=1 means the first HC165 in the chain. For a beginner this might be confusing.
In NG you can set the total number of scanned shiftregisters with this command:
SRIO num_sr=2Even though in this example I set num_sr=2 I can connect in total 4 shift registers. 2x HC165 and 2x HC595.
-
In your code you had assigned SR1 to both the keyboard and the DIO (J5A) module. This is invalid. You have to use a SR number that it not in use.
And the last pin on the 8th SR is Pin 64 (8x8). So the first pin on the 9th is 65.
-
Oh, really? I'll check again. If this is the case there must be a mistake somewhere else.
I'll report back.
But at least it's not true for receivers that receive sysex strings and forward them to displays. Correct?
Sharing: Adding capacitive touchsensor to midiBox
in MIDIbox NG
Posted
Any knob made from metal will do. Even a plastic knob should do. But you'd need to increase the cap between SNS and SNSK to make it more sensible.
I use knobs from Kobler here in Germany.