I am testing a single ledmeter for track 8, I’m using Ableton Live 5 and set up everything to work as mackie control (ID 14).
The fact is, the ledmeter is working but since I never dealt with digital meters (analogish school ) I was wondering if it is REALLY working fine.
My doubt arouse from the fact that the led meter stops after audio making me think of loss of sync (I have a midex 8 never had MIDI latency problems) and they lit very fast (epilessy!) Is it working normally?
another issue: is there a method to calibrate the ledmeters? It looks like at 1/3 of meter on Live the 9th led is yet lit
The LED meters are directly controlled from your host application, therefore “calibration” must be done there. Also the latency is an issue at the host side, MBLC controls the meters once the appr. MIDI events arive, normaly within less than 1 mS (especially USB interfaces have mostly a latency of more than 3..10 mS + an additional jitter)
The meter levels are decremented according to the Logic Control Spec (300 mS each LED). You can tune this value by changing the delay counter in lc_leds.inc, search for “15”, replace it by a higher number (up to 255)
Sorry but it seems I have more problems about mackie ledmeters…
The overload led (the 12th) does not lit.
hardware connections are ok
I’m not sure wether Live 5 is sending the flag or not
The array is not fully connected as I’m testing track 8 to finish the rest of it, so I connected D0 of J4 to the anodes of the track leds (the overload meter at the end) and the cathodes to the respective ports of j5 and j6 (cathode of the overload led to J6 D4)
Possibly a code issue? Does anybody who uses MBLC/ Live5 has experienced that problem?
Hi, I was looking to the pattern of meters, probably the cause resides in it.
LC_METERS_PatternSet
lfsr FSR1, METER_PATTERN_VPOT0_L ; calc pointer to pattern
clrc
rlf WREG, W ; add ringnumber * 2 (== ringnumber << 1) to pointer
addwf FSR1L, F ; (note: this function is not called by an interrupt routine,
; therefore we have to use FSR1)
;; calc pointer to table entry: LC_METER_PATTERNS + ((pattern index << 1)&0x1e)
TABLE_ADDR LC_METER_PATTERNS
rlf MIOS_PARAMETER1, W
andlw 0x1e
addwf TBLPTRL, F
movlw 0x00
addwfc TBLPTRH, F
;; pointer now in TBLPTR[LH], read first entry and increment pointer
tblrd*+
;; move table entry (TABLAT) to [iNDF0] and increment pointer by using POSTINC0
movff TABLAT, POSTINC1
;; read next table entry
tblrd*+
;; move table entry (TABLAT) to [iNDF0], don’t increment here
movf TABLAT, W
IFSET MIOS_PARAMETER1, 7, iorlw 0x08 ; set 12th (overdrive) LED if bit 7 of pattern index is set
movwf INDF1
Since the data shown on the leds is not very coeherent with the meters in Ableton live (when Live displays one third of meter full the LC meter has 9 of the 11 leds lit) , I assume I have to change the pattern. Could anybody point out a direction for me to achieve this?
Of course I noticed the pattern, but since the comment specifies “the 12th LED (overdrive) will be inserted automatically in LC_METERS_PatternSet” I was trying to understand if the overload meter led doesn’t lit because of the pattern. I’ll try to monitor with midiox if Live sends the overload flag, the pattern and Live responsibility are my only hope
anyway, I’m having some troubles deciphering the pattern: 1 stands for lit and 0 for not lit; but why 16 bits and 16 entries? Sorry if I ask I’m not a skilled programmer
Of course I noticed the pattern, but since the comment specifies “the 12th LED (overdrive) will be inserted automatically in LC_METERS_PatternSet” I was trying to understand if the overload meter led doesn’t lit because of the pattern. I’ll try to monitor with midiox if Live sends the overload flag, the pattern and Live responsibility are my only hope
The overload flag is parsed in lc_mproc.inc, function LC_MPROC_Received_D0 (read the comments there)
This routine copies the flag to METER_LEVEL_BEGIN + (meter number), bit number 7
The LC_METERS_PatternSet routine in lc_meters.inc checks for this flag and copies it to the bit position of the 12th LED
anyway, I’m having some troubles deciphering the pattern: 1 stands for lit and 0 for not lit; but why 16 bits and 16 entries?
16 bits, because the application allows you to control up to 16 LEDs per meter. However, since the host application only transfers 13 levels, and since my own MBLC has only 11 meter leds + one overload LED (when the meter values are displayed with the V-Pot LED-Rings), the remaining bits are 0.
16 entries: this is directly related to the maximum number of LEDs and levels.
The intention was, that this allows other people to change the patterns easily without asking me, how do do this exactly.
Hint: change the pattern temporary and watch for the effect. I think that this explains more than 1000 words!
) I was wondering if it is REALLY working fine.