help: trying to integrate snap into midibox64E (no success!!)

[bosone]

hi

i'm trying to modify mios code to handle the snap mode (only this) in the midiobox64E.

i have take a look at both mb64_pots.inc  and mb64e_fader.inc files, which seems to me that handle the pots value.

the routines are very similar, and i tried to "merge" the snap functions from mb64_pots.inc into the mb64e_fader.inc

so i added a call to the routine that do the snap mode in the section which sends the midi events

;; process snap mode

call MB64E_FADER_Conv

;; branch to the end if zero bit set

bz MB64E_FADER_Send_End

and removed the following two lines

;; store new value

call MB64E_FSR_FaderValue

movff MB64E_FADER_NEW_VALUE, INDF0

;; --------------------------------------------------------------------------
;;  This function is used to send a fader value
;;  Input:
;;     o fader number in MB64E_CURRENT_ENTRY
;;     o absolute position in WREG
;; --------------------------------------------------------------------------
MB64E_FADER_Send
	;; store current position in TMP1
	movwf	TMP1

	;; scale value depending on Min/Max entry
	;; calc address to Min/Max entry:
	call	MB64E_ADDR_FaderEntry
	;; select the 3rd byte
	movlw	3-1
	addwf	MB_ADDRL, F

	;; scale value:
	;; copy min value to MB64E_ENTRY_MIN_VALUE
	;; copy max value to MB64E_ENTRY_MAX_VALUE
	;; move fader value to WREG
	call	MB64E_BANK_Read
	movff	WREG, MB64E_ENTRY_MIN_VALUE
	call	MB64E_BANK_Read
	movff	WREG, MB64E_ENTRY_MAX_VALUE
	movf	TMP1, W
	call	MB64E_FADER_ScaleValue

	;; store result in MB64E_FADER_NEW_VALUE
	movff	WREG, MB64E_FADER_NEW_VALUE

	;; get pointer to FADER_VALUE_xx register
	call	MB64E_FSR_FaderValue

	;; store value in MB64E_FADER_VALUE
	movff	INDF0, MB64E_FADER_LAST_VALUE

	;; copy the new value into this location for the next call
	movff	MB64E_FADER_NEW_VALUE, INDF0

	;; if new value == old value, branch to the end
	SET_BSR	MB64E_BASE
	movf	MB64E_FADER_NEW_VALUE, W, BANKED
	xorwf	MB64E_FADER_LAST_VALUE, W, BANKED
	bz	MB64E_FADER_Send_End

	;; process snap/relative mode
	call	MB64E_FADER_Conv
	;; branch to the end if zero bit set
	bz	MB64E_FADER_Send_End

	;; send MIDI value
	call	MB64E_MIDI_SendFaderEvent

	;; clear request fader pos update
	bcf	MB_STAT3, MB_STAT3_FADER_UPDATE_REQ
;	bcf	MB_STAT3, MB_STAT3_FADER_SOFT_UPDATE_REQ

	;; request display update
	bsf	CS_STAT, CS_STAT_DISPLAY_UPDATE_REQ
	;; reset the cursor of the CS
	call	CS_MENU_ResetCursor

MB64E_FADER_Send_End
	return

and then i copid the complete routine that handles the snap mode. i changed all the names of the variables from "pot" to "fader" and also the routine labels from "mb64" to "mb64E". the code is assembled without error, but it doesnt work... it seems that the snap routine is never called... i also tried the relative routine (copied too in the inc file) but neither this seems to work. (note that i inserted a "rgoto" function which use by default one of the two routine - snap or relative). could you please help me? i think that there is something else to be considered, which is behiond my understanding of the code!!

;; --------------------------------------------------------------------------
;;  This function processes the new FADER value
;;  Input:
;;     o number of current FADER in MB64E_CURRENT_FADER
;;     o last value in MB64E_FADER_LAST_VALUE
;;     o new value in MB64E_FADER_NEW_VALUE
;;     o min value in MB64E_FADER_MIN_VALUE
;;     o max value in MB64E_FADER_MAX_VALUE
;;  Output:
;;     o processed/converted value in INDF0
;;       zero bit cleared when the value should be sent
;;
;;     taken from MB64E_pots.inc, only the snap or relative mode here is used by default
;; --------------------------------------------------------------------------
MB64E_FADER_Conv
	;; get pointer to FADER_VALUE_xx register (the active value)
	;; (controlled from MB64E if snap bit is set, or via MIDI)
	call	MB64E_FSR_FaderValue

	;; if soft takeover flag already set, jump to the end
	IFSET	INDF0, 7, rgoto MB64E_FADER_ConvBypass

	;; jump to the end if active value == new value
	movf	INDF0, W
	xorwf	MB64E_FADER_NEW_VALUE, W, BANKED
	bz	MB64E_FADER_ConvBypass

	rgoto MB64E_FADER_ConvRelative

	;; ------------------------------------------------------------------
MB64E_FADER_ConvSnap
	;; "snap" mode selected: "soft-takeover"

	;; branch depending on clockwise or counter clockwise turn
	;; means: last value <= new value
	movf	MB64E_FADER_LAST_VALUE, W, BANKED
	IFLEQ	MB64E_FADER_NEW_VALUE, BANKED, rgoto MB64E_FADER_ConvSnap_CClockwise
MB64E_FADER_ConvSnap_Clockwise
	;; FADER has been moved clockwise

	;; exit if if new value <= active value
	movf	INDF0, W
	IFLEQ	MB64E_FADER_NEW_VALUE, BANKED, rgoto MB64E_FADER_Conv_DontSend

	;; exit if active value >= last value
	IFGEQ	MB64E_FADER_LAST_VALUE, BANKED, rgoto MB64E_FADER_Conv_DontSend

	;; else continue
	rgoto	MB64E_FADER_ConvBypass

MB64E_FADER_ConvSnap_CClockwise
	;; FADER has been counter clockwise
	;; exit if if new value >= active value
	movf	INDF0, W
	IFGEQ	MB64E_FADER_NEW_VALUE, BANKED, rgoto MB64E_FADER_Conv_DontSend

	;; exit if active value <= last value
	IFLEQ	MB64E_FADER_LAST_VALUE, BANKED, rgoto MB64E_FADER_Conv_DontSend

	;; else continue
	rgoto	MB64E_FADER_ConvBypass


	;; ------------------------------------------------------------------
MB64E_FADER_ConvRelative
	;; "relative" mode selected:

	;; clear snap bit (will be set independent from last status)
	bcf	INDF0, 7

	;; calculate difference between last and new value
	movf	MB64E_FADER_LAST_VALUE, W, BANKED
	subwf	MB64E_FADER_NEW_VALUE, W, BANKED

	;; add difference to active value
	addwf	INDF0, F

	;; saturate:
	IFSET	WREG, 7, rgoto MB64E_FADER_ConvRelative_CCW
MB64E_FADER_ConvRelative_CW
	movf	0X7F, W, BANKED
	IFSET	INDF0, 7, rgoto MB64E_FADER_ConvRelative_Max
	IFLEQ	INDF0, ACCESS, rgoto MB64E_FADER_ConvRelative_Cont
MB64E_FADER_ConvRelative_Max
	movwf	INDF0
	rgoto	MB64E_FADER_ConvRelative_Cont

MB64E_FADER_ConvRelative_CCW
	movf	0X00, W, BANKED
	IFSET	INDF0, 7, rgoto MB64E_FADER_ConvRelative_Min
	IFGEQ	INDF0, ACCESS, rgoto MB64E_FADER_ConvRelative_Cont
MB64E_FADER_ConvRelative_Min
	movwf	INDF0
	rgoto	MB64E_FADER_ConvRelative_Cont

MB64E_FADER_ConvRelative_Cont
	rgoto	MB64E_FADER_Conv_Send


	;; ------------------------------------------------------------------


	;; ------------------------------------------------------------------
MB64E_FADER_ConvBypass
	;; save new value in active value
	movff	MB64E_FADER_NEW_VALUE, INDF0

	;; ------------------------------------------------------------------
MB64E_FADER_Conv_Send
	;; set snap bit
	bsf	INDF0, 7

	iorlw	0xff		; (clear zero bit)
	return

	;; ------------------------------------------------------------------
MB64E_FADER_Conv_DontSend
	andlw	0x00		; (set zero bit)
	return

the rest of the mb64e_fader.inc is the same

thank you!

[TK.]

Why did you open a new thread to the same topic?

As I already wrote, there is no memory free for snap mode - not only flash, but also RAM (snap mode requires a copy of the last pot values)

Please believe me that an enhancement into this direction requires a lot of conceptional changes in the MB64E (e.g. forget the possibility to handle 128 positions in RAM)

There is no 1-2-3 solution, otherwise you would find it already in the application (isn't this clear?)

Best Regards, Thorsten.

[bosone]

sorry for having upset you! :-)

i was thinking that you referred to the choice of snap/parallax/relative mode, the menu handling and so on.

i took a look at the code and i tseemed to me that the things to do, in order to add the snap mode behaviour by default, were just to copy some lines...

now i understand that things are more complicate (even if i don't understand!!) because perhaps of the different mios basic routines for mb64e...

[TK.]

Thanks for your understanding :)

The big difference of MB64E compared to MB64 is, that 128 encoder events + 64 button events are stored in RAM, and the MIDI receiver can parse for these events at the same time. The MB64 can only handle 64 pots and 64 button events, therefore there is enough RAM free for features like the snap mode.

If - for example - the MIDI events wouldn't be free configurable, but hard programmed (e.g. only CCs at a specific channel), the RAM consumption would be much less, and it would be a piece of cake to include an additional soft-takeover function for the pots.

But MB64E was designed into another direction (high flexibility, high number of parameters).

And programming an application with a different concept would basically mean twice the effort.

However, maybe you should have a look into the upcoming C based MIOS application, where changes can be made much easier. E.g., there isn't an "app_defines.inc" file anymore, you can declare variables and arrays directly within a .c file, and the compiler/linker will take care for the memory allocation. This makes it easier to copy features from one into another application.

Best Regards, Thorsten.

[bosone]

just to know a little more...

the 128 encoder events and 64 buttons are used regardless of how many physical encoder are acutally used?

theoretically, since i have only 16 buttons/16 encoders, could i "free" some memory and use it for the snap, by deleting the 128-16 encoders that are acutally not-existent?

ot the memory location for all the 128 encoder are always used even if only a single encoder is mounted?

[TK.]

Yes, they are always used. The reason is, that this allows to switch very fast between different views.

E.g, with a single encoder you are still able to access (receive and send) up to 128 parameters, isn't this a great possibility? :)

This was a request by some users, it was hard work to realize this, and now its unfortunately very difficult to remove this feature (due to heavy code optimizations)

If you only need such primitive controller features, I would suggest to program something based on the C wrapper instead.

Just wait some weeks/months until all examples are available, it will be much easier to combine the C modules to the controller of your dreams than trying to modify such a complex application like MB64E

Best Regards, Thorsten.