nlate
-
Posts
68 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by nlate
-
-
Hello Thorsten
Details are described in the README.txt
"
...
MIOS32_SRIO_ScanStart is now called immediately (again) when a scan has finished,
accordingly only the transfer rate limits the scan speed. It has been set to
MIOS32_SPI_PRESCALER_64 (0.64 uS on a 120 MHz LPC1769).
The resulting matrix scan speed is ca. 300 uS for 16 rows and 8 columns (= 512 contacts)
....
"
I don´t understand your calculation.
As far as I can follow there are 2 ser. DOUT register for the rows an 1 ser. DIN register for the columns which lead to 16 x 8 = 128 contacts or 64 early & final contacts pairs.
This means for me 64 keys with velocity sensing.
Supposing (16 bits [for DOUT] + 8 bits [for DIN])/row * 0.64 uS/bit * 16 rows = 246 uS plus some spare processing time leads to the aforementioned 300 uS scan time but for 128 contacts.
Where is my error in reasoning?
Regards
Jo
-
I don't want to mess with this side of the desk channel, so the best approach is probably to use the "equivalent" motorized fader from Penny & Giles, the PGFM 8160 with an iron-core motor that can be driven by 5-11.5 volts (8 V nominal). This fader seems to fit in the mixing desk module I use from what I can see from the PG site.
I start small now (expensive faders)...
Hi Finis
Before you start with the (more expensive) PGFM 8160.
There is one small detail on mot. Alps K faders which makes them perform better than the P&G faders.
A small plastic guide mounted on the pulley side of the Alps Fader makes it more responsive when the fader motor changes its direction.
This tiny small part makes the control SW much more strait forward (less deadband / hysteresis on direction change)
Regards
Jo
-
Regarding the faders, I went immediately to the studio today and to my amazement I see that the faders in the desk are Penny & Giles PGF 8000 Series, not Alps as I said earlier. The PG faders are narrow (13.4 mm) I am afraid and, hence, there are few alternatives. At present, the 15 mm Alps Motor K fader (CP type) RSA0K11V901S seems to be an option if I can narrow the width down a bit somehow. Hence, before starting all this, I need to check if I can cram the new faders into the compact console slots.
First action on my part: Get an Alps Motor K fader RSA0K11V901S and tweak.
Hello Finis,
A very ambitious project you have in mind.
Following questions should be checked in advance of buying 72 motorized Alps K faders:
- Do the Calrec consoles have VCAs for channel volume control?
Because the mot. Alps K Faders only have Linear 10k tracks. a log. tapper is not available as motorized. K type afaik.
So, your PGF 8000 fader should be of type PGF8110/8112 or 8160 type (Lin. or VCA type) - The fixing holes of both fader types are 120 mm appart, so no problem
but the overall length of the ALPS K Fader is larger on buttom (pulley) and top (motor).
so ensure that you have enough space in the consoles channel strip fader area.
Regards
Jo
- Do the Calrec consoles have VCAs for channel volume control?
-
Hi Ilmenator
Sorry for the confusion
MIDI is such a slow protocol in itself that it does not matter whether there is data coming in or not for the latency considerations you are discussing.
Just for clarification:
I know about the slow MIDI transfer rate. My interest (lack of knowledge) is more on the Core MIOS32 side.
With " the serial protocol bus nature" I mean the IIC bus.
So I reformulate my question:
Does the scheduler of the MIOS allow processing of only one IIC per 10uS time slot
or
are the 10uS per IIC Input device caused by the IIC "arbitration" if more than one IIC MIDI module has MIDI data on its input, ready to send to the Core?.
I hope this makes my previous question more clear.
Regards
Jo
-
Hello Thorsten
just a question about IIC MIDI Input Iatency:
MIDI OUT ports don't add latency
Each HW based MIDI IN port adds a latency of ca. +1 uS (the MBHP_CORE_LPC17 module has 4 UART inputs)
Each IIC based MIDI IN port adds ca. +10 uS latency if the receive interrupt signal can be directly connected to the core module.
Each IIC based MIDI IN port adds ca. +50 uS latency if the receive status has to be polled.
Does this mean for e.g. 4 IIC MIDI Inputs
a latency of 4x10 uS = 40 uS has to be added, independent of the amount of the MIDI msgs on the IIC MIDI Inputs
or
is this just for the worst case scenario caused by the serial protocol bus nature, if all 4 IIC MIDI have data to transfer to the CORE module?
Regards
Jo
-
Dear Thorsten,
the 4 PCB and 4 MagJacks arrived yesterday.
Thank you very much (thanks also for soldering the MagJacks :thumbsup:)!
Regards
Jo
-
Kernlos, gekapselt, linear, die Gleichen, die in den Digidesign HUIs sind.
Auf dem Bild ist aber die "Billigversion" ALPS RSAOK11VP mit Standard Motor NICHT 'coreless' zu sehen.
Coreless ist ALPS RSAOK11W und sieht so aus: http://www.ucapps.de/mbhp/mf/final/rsaok11w.jpg
Gruss
Jo
-
Thanks Thorsten for your immediate response.
Your answer to my 1st question rel. the USB MIDI protocol makes sense, I have also to admit: Never change a winning team!
Your comments to the 2nd question are reasonable.
Btw I used the trick with the lookup table in IIC_CMD.asm for dispatching the incomming IIC commands.
Your concerns about using a branchtable (the 256 byte page limit) are true and for that purpose I used markers for the begin and end of the table to verify no page overlap in the map file (s. IIC_CMD_TableBegin & IIC_CMD_TableEnd).
I know, that there is a chance to trap in this pitfall. But the map file should be checked anyway if anything gets to be changed.
Jo
-
I did some PIC Assembler programming in the last few weeks, implementing nearly all routines used for the protocol proposal.
The initial proposal needed some modifications and enhancements during implementation. (s. attachment)
I have to admit that I was not able to burn the code to a real target device up to now. This will follow in the next week(s)
But the current state of the asm code is assembled successfully (s. *.map file)
I could also post the sources here as *.zip.
Imho my code is not ready to be put in the svn repository.
What is missing a.t.m. is the trigger input handling via interrupt for scheduled MIDI Realtime Commands on MIDI output
One of my preconditions (leaving the HW untouched) in my initial post could no be fullfilled completely:
- to make use of the trigger input via interrupt, the Port pins need to be rearranged to make a PortB pin available. (only PortB pins can generate interrupts)
If this function is not needed by the host and if not more than 4 IIC_MIDI devices are used, only one jumper has to be set to connect RA5 to GND (J1: Vs o-o X3)
If scheduled command processing on MIDI output and/or more than 4 devices, a rearrangement of the Jumpers and insertion (soldering) of 4 additional 10k Pull-Up resistors has to be done:
1. use RB6 as low-active trigger Input (ID0 on J3)
2. install 4 x 10k Pull-Up Resistors on the solder side of the PCB
2.1 RA2 -> 10k -> Vdd (e.g. IC1: Pin1 -> 10k -> Pin14)
2.2 RA3 -> 10k -> Vdd (e.g. IC1: Pin2 -> 10k -> Pin14)
2.3 RA4 -> 10k -> Vdd (e.g. IC1: Pin3 -> 10k -> Pin14)
2.4 RA5 -> 10k -> Vdd (e.g. IC1: Pin4 -> 10k -> Pin14)
3. Use J1 as IIC Address terminal (Address (0x10..0x1f):
3.1 Vs o-o X0 -> ID0
3.2 Vs o-o X1 -> ID1
3.3 Vs o-o X2 -> ID2
3.4 leave X3 open!
Here some questions mainly addressed to Thorsten about his implementation:
1. Why must the 0xff command for entering the IIC Command state be handled by a state machine?
Imho it is a violation of the USB protocol anyway, because MIDI Reset cmd (0xff) should be sent as 0x0f (single byte) and not as 0x03 (three-byte sys-comm msg).
2. Prot.asm: the table access fct. for e.g. EXPECTED_BYTES_COMMON_TABLE suggest that the tables reside in the EEPROM area.
But the tables reside in the normal programm area.
Is there not a simpler and faster way to access them?
Comments and suggestions wellcome!
Jo
-
I use a Roland M-480 Rack mixer connected to a creamware Scope PCI Card with analog I/O.
(24 Stereo Inp. -> 2 x Stereo Outs; 6 Aux rails, 4x AF, 2x Pre/AF selectable)
All my rack Synths are hardwired to the Inputs;
PCI Card In is feed by SubOut.
PCI Card Out -> Inp. 47/48 (last stereo Inp.)
Main Out goes to the Monitor LS
As you already mentioned, any kind of analog HW mixer is essential for PC-less jamming /playing.
Even my wife can activate & play my rig :rolleyes:(she's a music teacher). This is essential for me to justify frurther investments :wink:
One big advantage over conventional tabletop Desk is its vast functionality in its small 6U 19" Rackspace.
Regards
Jo
-
I gave you access to the programmers section where you will find informations about the latest developments (especially about MIOS32 and the new core module)
Thank you very much, Thorsten!
I guess that you would add the MBHP_IIC_MIDI extensions by yourself?
This is the hardest part, as I'm not familiar with PIC assembler programming. I've always some tutorial sites open on my 2nd screen, when I (try to) code PIC assembler.
Regards,
Jo.
-
Dear Thorsten, dear MIDIBOX community
Since several months I have the idea of a sophisticated MIDI Patchbay/rtp-MIDI LAN device in my mind based on your beloved IIC-MIDI & MIOS32 Hardware platform.
After some top-down and bottom-up mindgames, I started buttom-up by defineing a iic interface protocol for interconnection the STM32 Module with the iic midi IF.
Motivation:
The MIDIBOX IIC MIDI Module (s. http://www.ucapps.de/mbhp_iic_midi.html) can be enhanced to act as a pair of "intelligent" MIDI sockets,
keeping away the computational load of basic MIDI protocol processing in a host as the CORE_STM32 Module.
The MIOS32 based host then can then handle the more application specific tasks like a MIDI patchbay (eventually with a LAN Interface for processing the rtp-MIDI protocol stack)
or a MIDI Sequencer like the current MIDIbox SEQ V4 (maybe V5).
What would be nice to have as enhancement for the curent implementation:
1. Filter/Mute commands for MIDI IN and MIDI OUT to minimize transfer of unused commands on MIOS_IIC_ByteReceive and on MIDI OUT line:
1.1 MIDI Channel Voice msg
1.2 MIDI SYSTEM COMMON msg
1.3 MIDI SYSTEM REALTIME msg
2. Autonomous handling of Active Sensing without involving the host under normal operation conditions.
(Active Sensing may be usefull to dectect cable breaks or unintended power losses in a networked remote environment)
3. Handling of Running Status on MIDI Input & Output
4. Exact same REALTIME Command execution on all MIDI Outs.
Since the actual IIC implementation of the PIC 16F88 lacks of the broadcast address definition, this could be achieved by using a scheduled
(delayed) command which is processed when a dedicated pin, common for all IIC MIDI modules is triggered by the host.
5. Prioritized processing of REALTIME commands at MIDI Input
6. PANIC (Sequence of All Notes off, Reset all controllers etc. on all MIDI channels) on MIDI Output.
7. Housekeeping commands. (Initialize, Bufferstatus, Reset)
Preconditions for this protocol enhancement:
- downward compatibility to the current IIC_MIDI transfer protocol
- No violation of Thorsten´s inspiration from the USB MIDI specification.
- use of the current hardware platform (s. http://www.ucapps.de...hp_iic_midi.pdf)
- IIC addr. extension from 4 to 8 slave devices (maybe RA2?) on J1
- 1 additional interrupt generating input pin (maybe RA3?) on J1 as a common "execute" signal for scheduled MIDI Realtime Commands (s. below)
Additional RAM resources used in PIC16F88 (1st guess):
1. MUTE Patterns
1.1 Channel Voice msg: 16 bytes
1.2 SYSTEM COMMON msg: 1 byte
1.3 SYSTEM REALTIME msg: 1 byte
18 bytes/direction => 36 bytes in unused GPR1
2. Additional SYSTEM REALTIME cmd handling
2.1 Prioritized REALTIME msgs: 4 x 1 byte
2.2 Scheduled REALTIME msgs: 4 x 1 byte
8 bytes in SHARED RAM area (73..7F)
3. Active Sensing Processing: ca. 4-8 bytes in GPR1
4. Additional states: ca. 4 bytes in SHARED RAM or GPR0 area
Comments and suggestions wellcome!
Regards
Jo
-
Hallo Jan, Hallo Nils
Selbstverständlich dürfen MIDI Realtime Commands wie F8 jederzeit gesendet werden auch zwischen 3-byte Befehlen oder innerhalb eines Sysex Streams.
MIDI Realtime commands sind immer 1byte Statusbytes mit gesetztem MSB. Sie haben immer Priorität, sonst entsteht ein MIDI Clock jitter (MIDI wackelt auf der 31k25 Leitung schon schlimm genug.
Details dazu in der "MIDI 1.0 Detailed Specification" Seite 35
Gruß
Jo
-
Hi nILS
My boards arrived yesterday
Thanks a lot for your effort
Regards
Jo
-
Hi Chris
I got my 4 Displays yesterday.
Thanks again for your effort
Regards
Jo
-
Hi Robin
Last weekend I had found some time to evaluate my latest toy, a LOGICPORT LOGIC ANALYZER from http://www.pctestinstruments.com/. I have a cheap Fatar TMK88, with aTP9 Keybed and a PIC16F74 build in, as a candidate to see the Logicport in action.
Fatar actually uses the BR0..BR10 & MK0..MK10 signals as strobes (active low signals) and monitors the data lines T0..T7, which are connected to a parallel PIC port via 2k2 pullups. The data lines represent 8 keys, because the BRx strobes scans the break (upper) switches, and the MKx strobes scans the make (lower) switches.
1. Transition from untouch -> key-press: when Data Out: BRx 1->0: => Data In: T0..7 1->0.
2. Before reaching the lower key position: when Data Out: BRx 1->0: => Data In: T0..7 = 0.
3. Reaching the lower key position: when Data Out: BRx 1->0: => Data In: T0..7 = 0; when Data Out: MKx 1->0 => Data In: T0..7 1->0.
The scanning procedure for the whole keyboard is repeated every 400 usec.
The clever thing is that only the BR0..10 scanlines are strobed as long as no key-presses are detected.
If any key-press is detected (BR0..BRx..BR10; BRx 1->0 => T0..7 1->0) the related MKx will also be activated in the next scan period like BR0, BR1..BRx, MKx, BRx+1..BR10.
Some Timing Data
BRn -> BRn+1 : 6 usec
BRn, MKn, Tn low (0) time: 1.5 usec
BR0..BR10 scanning duration (no key pressed): 60 usec
BR0..BRx,MKx..BR10 scanning duration (1 key pressed): 66 usec => 60 usec + (count of MK strobes)*6 usec
Scanning procedure repeat time: 400 usec
So processing can take place in 400 usec - 22*6 usec: 268 usec
These are my 2 cents to the never ending but enlightening key velocity scanning discussion in this fantastic forum.
Regards
Jo
Tutorial #029: Fast Scan Matrix for velocity sensitive Keyboard
in MIOS programming (C)
Posted
Hi Thorsten,
Thanks for correcting the Readme.txt
Aah, I forgot, that's the nature of SPI,
Regards, Jo