The Ekdahl FAR - Command language - Revision history

Knaadmin: Knaadmin moved page The Ekdahl FAR - Command language (1.0) to The Ekdahl FAR - Command language over redirect

2026-06-12T10:46:04Z

Knaadmin moved page The Ekdahl FAR - Command language (1.0) to The Ekdahl FAR - Command language over redirect

← Older revision	Revision as of 06:46, 12 June 2026
(No difference)

Knaadmin: Knaadmin moved page The Ekdahl FAR - Command language to The Ekdahl FAR - Command language (1.0)

2026-06-12T10:45:15Z

Knaadmin moved page The Ekdahl FAR - Command language to The Ekdahl FAR - Command language (1.0)

← Older revision	Revision as of 06:45, 12 June 2026
(No difference)

Knaadmin at 10:32, 12 June 2026

2026-06-12T10:32:53Z

← Older revision		Revision as of 06:32, 12 June 2026
Line 248:		Line 248:
	The commands responsible for changing the CV mapping are located in the "controlbox"-module, these are		The commands responsible for changing the CV mapping are located in the "controlbox"-module, these are

	* '''harmonic''' - Sets the ''commands'' executed when the "Harmonic"-knob or modulation changes		* '''harmonic''' '''/ har''' - Sets the ''commands'' executed when the "Harmonic"-knob or modulation changes
	* '''harmonicshift''' - Sets the ''commands'' executed when the "Harmonic shift"-knob or modulation changes		* '''harmonicshift''' '''/ has''' - Sets the ''commands'' executed when the "Harmonic shift"-knob or modulation changes
	* '''finetune''' - Sets the ''commands'' executed when the "Fine tune"-knob changes		* '''finetune / fin''' - Sets the ''commands'' executed when the "Fine tune"-knob changes
	* '''pressure''' - Sets the ''commands'' executed when the "Pressure"-knob or modulation changes		* '''pressure''' '''/ pre''' - Sets the ''commands'' executed when the "Pressure"-knob or modulation changes
	* '''mute''' - Sets the ''commands'' executed when the "Mute"-knob or modulation changes		* '''mute''' '''/ mut''' - Sets the ''commands'' executed when the "Mute"-knob or modulation changes
	* '''hammerscale''' - Sets the ''commands'' executed when the "Hammer scale"-knob changes		* '''hammerscale / hms''' - Sets the ''commands'' executed when the "Hammer scale"-knob changes
	* '''gate''' - Sets the ''commands'' executed when the "Gate"-switch or modulation changes		* '''gate / gt''' - Sets the ''commands'' executed when the "Gate"-switch or modulation changes
	* '''hammertrig''' - Sets the ''commands'' executed when the "Hammer Trig"-button or modulation changes		* '''hammertrig''' '''/ hmt''' - Sets the ''commands'' executed when the "Hammer Trig"-button or modulation changes
	In order to set/retrieve ''mapping data'' we just use a regular "rqi"-''command''. To for instance get the ''command string'' executed when the "~~harmonic~~" knob or modulation is sent we can do the following		In order to set/retrieve ''mapping data'' we just use a regular "rqi"-''command''. To for instance get the ''command string'' executed when the "pressure" knob or modulation is sent we can do the following
	'''FAR < 1.1:'''		'''FAR < 1.1:'''
	[send] rqi:acm:0		[send] rqi:acm:3
	[returns] [irq]acm:0:'~~bcha~~:value~~/1327.716667-20~~'		[returns] [irq]acm:3:'bpb:value'

	'''FAR 1.1:'''		'''FAR 1.1:'''
	[send] rqi:controlbox.~~harmonic~~		[send] rqi:controlbox.pressure
	[returns] [irq]cb[0].~~har~~:'bw.~~hsh~~.ha:value~~/1327.716667-20~~'		[returns] [irq]cb[0].pre:'bw.bp.ba:value'
	~~What is returned is~~ the ''~~command~~'' ~~to set~~ the ''~~harmonic~~'' ~~with a ''parameter'' of "value/1327.71667-20"~~		As can be seen, when the ''pressure'' knob or modulation changes, the new data read by the ADC (stored in the "value"-''variable'') is sent to the ''command'' controlling the ''bow pressure baseline.'' Hopefully at this point it is obvious that making the knob and jack on the ''control box'' that is labeled as "Pressure" do something completely different, is quite easy - just remap the ''command string''.{{docnav
	~~We retrieve~~ the ''command ~~string~~'' ~~for channel~~ ''0'' ~~which reads~~ the ~~sum of~~ the ''~~harm. v/oct~~''-~~jack and~~ the ''~~harmonic~~''~~-knob by sending a command of~~

	~~The <u>default</u> response will be something like~~

	{{docnav
	\|[[The Ekdahl FAR - Service\|Service]]		\|[[The Ekdahl FAR - Service\|Service]]
	\|[[The Ekdahl FAR - Command reference\|Command reference]]		\|[[The Ekdahl FAR - Command reference\|Command reference]]
	}}		}}

Knaadmin at 10:12, 12 June 2026

2026-06-12T10:12:26Z

← Older revision		Revision as of 06:12, 12 June 2026
Line 230:		Line 230:

	== CV Mapping ==		== CV Mapping ==
	''CV Mapping'' works exactly like the ''MIDI mapping'' with the difference that the command for setting the ''CV mapping'' is different and that ~~<u>~~all~~</u> events pertaining to this <u>only</u> change~~ the "value"-''variable''.		''CV Mapping'' works exactly like the ''MIDI mapping'' with the difference that the command(s) for setting the ''CV mapping'' is different and that they all modify (and thus share) the "value"-''variable''. These ''events'' are triggered whenever the analog-to-digital converter senses a change in a control or modulation jack, if you use something like an LFO with the modulation jacks here you will get a LOT of events and subsequent ''commands'' being sent.
	'''FAR < 1.1:'''		'''FAR < 1.1:'''

Line 256:		Line 256:
	* '''gate''' - Sets the ''commands'' executed when the "Gate"-switch or modulation changes		* '''gate''' - Sets the ''commands'' executed when the "Gate"-switch or modulation changes
	* '''hammertrig''' - Sets the ''commands'' executed when the "Hammer Trig"-button or modulation changes		* '''hammertrig''' - Sets the ''commands'' executed when the "Hammer Trig"-button or modulation changes
			In order to set/retrieve ''mapping data'' we just use a regular "rqi"-''command''. To for instance get the ''command string'' executed when the "harmonic" knob or modulation is sent we can do the following
			'''FAR < 1.1:'''
			[send] rqi:acm:0
			[returns] [irq]acm:0:'bcha:value/1327.716667-20'

			'''FAR 1.1:'''
			[send] rqi:controlbox.harmonic
			[returns] [irq]cb[0].har:'bw.hsh.ha:value/1327.716667-20'
			What is returned is the ''command'' to set the ''harmonic'' with a ''parameter'' of "value/1327.71667-20"
	We retrieve the ''command string'' for channel ''0'' which reads the sum of the ''harm. v/oct''-jack and the ''harmonic''-knob by sending a command of		We retrieve the ''command string'' for channel ''0'' which reads the sum of the ''harm. v/oct''-jack and the ''harmonic''-knob by sending a command of

	The <u>default</u> response will be something like		The <u>default</u> response will be something like
	~~<pre>[irq]acm:0:'bcha:value/1327.716667-20'</pre>~~

	{{docnav		{{docnav
	\|[[The Ekdahl FAR - Service\|Service]]		\|[[The Ekdahl FAR - Service\|Service]]
	\|[[The Ekdahl FAR - Command reference\|Command reference]]		\|[[The Ekdahl FAR - Command reference\|Command reference]]
	}}		}}

Knaadmin at 09:37, 12 June 2026

2026-06-12T09:37:55Z

@@ Line 136: / Line 136: @@
 == MIDI mapping ==
 The way ''MIDI'' works int the Ekdahl FAR is that each ''MIDI message'' is associated with a certain ''command string'' and the ''MIDI message'' will also update some of the internal ''variables''. Any time the associated ''MIDI message'' is received the Ekdahl FAR will execute the ''commands'' that have been associated with that ''MIDI message''. Several ''MIDI configurations'' can be stored and recalled at any time, each with a different set of ''commands'' associated with each ''MIDI message''.
   '''FAR < 1.1'''
@@ Line 232: / Line 230: @@
 == CV Mapping ==
-''CV Mapping'' works exactly like the ''MIDI mapping'' with the difference that the command for setting the ''CV mapping'' is different and that <u>all</u> events pertaining to this <u>only</u> change the ''value''-variable. The ''command'' for changing the ''CV mapping'' is ''adccommandmap'' or ''acm'', it take two ''parameters''; ''channel'' and ''command string''. We retrieve the ''command string'' for channel ''0'' which reads the sum of the ''harm. v/oct''-jack and the ''harmonic''-knob by sending a command of<pre>
+''CV Mapping'' works exactly like the ''MIDI mapping'' with the difference that the command for setting the ''CV mapping'' is different and that <u>all</u> events pertaining to this <u>only</u> change the "value"-''variable''.
-rqi:acm:0
+ '''FAR < 1.1:'''
-</pre>The <u>default</u> response will be something like
 <pre>[irq]acm:0:'bcha:value/1327.716667-20'</pre>

Knaadmin at 09:04, 12 June 2026

2026-06-12T09:04:31Z

← Older revision		Revision as of 05:04, 12 June 2026
Line 179:		Line 179:
	</pre>The first part of the return message tells us that the incoming message is of "rqi"-type ("[irq]") which means it's responding to a information request ''command'' sent. The second part tells us what ''command'' the information request return is responding to and any ''parameters'' that may be pertinent. The third part of the message is the actual data stored.		</pre>The first part of the return message tells us that the incoming message is of "rqi"-type ("[irq]") which means it's responding to a information request ''command'' sent. The second part tells us what ''command'' the information request return is responding to and any ''parameters'' that may be pertinent. The third part of the message is the actual data stored.

	For the FAR < 1.1 the data returned is for the ''command'' "mev" with the first ''parameter'' set to "pb", the ''command reference'' tells us this means the ''command'' "midieventhandler" and the ''parameter'' "pb" indicates this has to do with the ''pitch bend''. The data is "bowcontrolharmonicshift*4".		For the FAR < 1.1 the data returned is for the ''command'' "mev" with the first ''parameter'' set to "pb", the ''command reference'' tells us this means the ''command'' "midieventhandler" and the ''parameter'' "pb" indicates this has to do with the ''pitch bend''. The data is "bowcontrolharmonicshift:pitch*4".

	For the FAR 1.1 the data returned is for the ''command'' "bw[0].mcf[0].mc[0].pb" (bowinwheel[0].midiconfigurationhandler[0].midiconfiguration[0].pitchbend) and the data is "bowingwheel.harmonicserieshandler.harmonicseries.shift:pitch*4". Note here that if we have several different ''MIDI configurations'' stored and we're currently using configuration number 2, the returned message would have been "bw[0].mcf[0].mc[2].pb".		For the FAR 1.1 the data returned is for the ''command'' "bw[0].mcf[0].mc[0].pb" (bowinwheel[0].midiconfigurationhandler[0].midiconfiguration[0].pitchbend) and the data is "bowingwheel.harmonicserieshandler.harmonicseries.shift:pitch*4". Note here that if we have several different ''MIDI configurations'' stored and we're currently using configuration number 2, the returned message would have been "bw[0].mcf[0].mc[2].pb".
Line 203:		Line 203:
	Now let's break down what happens when this ''MIDI message'' is received, i.e. when a ''MIDI'' key is pressed down:		Now let's break down what happens when this ''MIDI message'' is received, i.e. when a ''MIDI'' key is pressed down:

	# "bchb:note" / "bw.hsh.hb:note" - Invokes the "bowcontrolharmonicbase" / "harmonicserieshandler.harmonicbase"''-command'' with the first ''parameter'' set to the ''variable ~~note~~''. This sets the ''base harmonic'' that the Ekdahl FARs ''bowing motor'' should be set to. Here the ''variable'' "note" is used which is simply the MIDI key being pressed down, it is automatically converted by the ''command'' to the corresponding harmonic in the ''harmonic list''		# "bchb:note" / "bw.hsh.hb:note" - Invokes the "bowcontrolharmonicbase" / "harmonicserieshandler.harmonicbase"''-command'' with the first ''parameter'' set to the ''variable "''note". This sets the ''base harmonic'' that the Ekdahl FARs ''bowing motor'' should be set to. Here the ''variable'' "note" is used which is simply the MIDI key being pressed down, it is automatically converted by the ''command'' to the corresponding harmonic in the ''harmonic list''
	# "bmr:1" / "bw.dcm.ru" - Sets the "bowmotorrun" / "dcmotor.run"-command to '1', starting the ''bow motor''		# "bmr:1" / "bw.dcm.ru" - Sets the "bowmotorrun" / "dcmotor.run"-command to '1', starting the ''bow motor''
	# "bpid:1" / "bw.pe:1" - Sets the "bowpid" / "bowingwheel.pidenable"-''command'' to '1'. Basically this enables the function that makes the Ekdahl FAR able to keep a stable frequency on the ''bowing motor''.		# "bpid:1" / "bw.pe:1" - Sets the "bowpid" / "bowingwheel.pidenable"-''command'' to '1'. Basically this enables the function that makes the Ekdahl FAR able to keep a stable frequency on the ''bowing motor''.
	# "bpe:1" / "bw.bp.en" - Sets the "bowpressureengage" / "bowpressure.engage"-''command'' to '1' which moves the ''bowing jack'' to the ''engage position'', aka just below the string if not additional ''pressure'' is applied		# "bpe:1" / "bw.bp.en" - Sets the "bowpressureengage" / "bowpressure.engage"-''command'' to '1' which moves the ''bowing jack'' to the ''engage position'', aka just below the string if not additional ''pressure'' is applied
	# "se:(velocity512)(1-notecount)" / "so.en:(velocity512)(1-notecount)" - Executes the "solenoidengage" / "solenoid.engage"-''command'' with the value ''(velocity512)(1-notecount)''. This will make the ''solenoid'' strike the ''hammer'' with a force that is dependent on the ''~~velocity~~'' ~~variable~~ sent by the ''Note On MIDI message'' in order to make the ''hammer'' velocity sensitive. But it also adds the somewhat perplexing part "*(1-notecount)". "notecount" is a global ''variable'' that contains the number of MIDI keys that are currently being held down. If "notecount" is anything above zero, the outcome of the equation will either be zero or a negative number. The "solenoidengage" / "solenoid.engage"-''command'' requires a ''16-bit unsigned'' value, aka the only valid numbers are 0 - 65535. Anything below 0 will be interpreted as zero, so what this equation does is that it only fires off the ''hammer'' if there are no previous keys being held down - it's being used in ''staccato'' mode.		# "se:(velocity512)(1-notecount)" / "so.en:(velocity512)(1-notecount)" - Executes the "solenoidengage" / "solenoid.engage"-''command'' with the value ''(velocity512)(1-notecount)''. This will make the ''solenoid'' strike the ''hammer'' with a force that is dependent on the "velocity"-''variable'' sent by the ''Note On MIDI message'' in order to make the ''hammer'' velocity sensitive. But it also adds the somewhat perplexing part "*(1-notecount)". "notecount" is a global ''variable'' that contains the number of MIDI keys that are currently being held down. If "notecount" is anything above zero, the outcome of the equation will either be zero or a negative number. The "solenoidengage" / "solenoid.engage"-''command'' requires a ''16-bit unsigned'' value, aka the only valid numbers are 0 - 65535. Anything below 0 will be interpreted as zero, so what this equation does is that it only fires off the ''hammer'' if there are no previous keys being held down - it's being used in ''staccato'' mode.
	# "bcsm:0" / "bowingwheel.speedmode" - Sets the "bowcontrolspeedmode" / "bowingwheel.speedmode" to '1' which enables automatic shut down of the ''bowing motor'' after a given timeout.		# "bcsm:0" / "bowingwheel.speedmode" - Sets the "bowcontrolspeedmode" / "bowingwheel.speedmode" to '1' which enables automatic shut down of the ''bowing motor'' after a given timeout.
	Let's postulate that the Ekdahl FAR is tuned to a 'C' at 65.4Hz and has its ''base'' set to middle 'C' (''MIDI key'' no 36). We are using the equal-temperament 12-tone scale and the Ekdahl FAR is set to respond to <u>all</u> ''MIDI channels'' (omni). Without having previously held any keys we press the middle 'C' (''note'' value 36) as hard as possible (''velocity'' value ''127'') on ''MIDI channel'' number 1 (''channel'' value of 0). The Ekdahl FAR will get a ''note on MIDI message'' sent to it and from our mapping it will create the following ''command string''<pre>[irq]mev:noteon:'~~m:0,b:0,~~bchb:36,bmr:1,bpid:1,bpe:1,se:(127512)(1-0),bcsm:0'</pre>What has happened here is that all ''variables'' have been replaced with the values sent by the ''MIDI message''. Since those ''commands'' that doesn't have any ''variables'' with them will execute just as previously, only those ''commands'' whos ''parameters'' have changed will be explained:		Let's postulate that the Ekdahl FAR is tuned to a 'C' at 65.4Hz and has its ''base'' set to middle 'C' (''MIDI key'' no 36). We are using the equal-temperament 12-tone scale and the Ekdahl FAR is set to respond to <u>all</u> ''MIDI channels'' (omni). Without having previously held any keys we press the middle 'C' (''note'' value 36) as hard as possible (''velocity'' value ''127'') on ''MIDI channel'' number 1 (''channel'' value of 0). The Ekdahl FAR will get a ''note on MIDI message'' sent to it and from our mapping it will create the following ''command string''<pre>FAR < 1.1:
			[irq]mev:noteon:'bchb:36,bmr:1,bpid:1,bpe:1,se:(127512)(1-0),bcsm:0'

	# '~~'bchb~~: 36'' ~~- The~~ ''~~bowcontrolharmonicbase~~'' gets a value of ''36'' (middle 'C'), because ''harmonic number 0'' is mapped to this key it will set the ''bowing wheel'' frequency to the ''fundamental''; ''65.4'' Hertz		FAR 1.1:
	# ''se: (127512)(1-0)'' - the value of ''127'' comes from the ''~~velocity~~''~~-variable~~, ''127 * 512 = 65024'' which is awfully close to a maximum hammer force of 65535. Since no previous notes were held down ''notecount'' is equal to ''0'' and thus ''65024 * 1 = 65024''. The hammer is engaged with near maximum force.		[irq]mcf[0].mc[0].non:'bw.hsh.hb:36,bw.dcm.ru:1,bw.pe:1,bw.bp.en:1,so.en:(127512)(1-0),bw.sm:0'</pre>What has happened here is that all ''variables'' have been replaced with the values sent by the ''MIDI message''. Since those ''commands'' that doesn't have any ''variables'' with them will execute just as previously, only those ''commands'' whos ''parameters'' have changed will be explained:

			# "bchb: 36" / "bw.hsh.hb:36" - The "bowcontrolharmonicbase" / "harmonicserieshandler.harmonicbase" gets a value of ''36'' (middle 'C'), because ''harmonic number 0'' is mapped to this key it will set the ''bowing wheel'' frequency to the ''fundamental''; ''65.4'' Hertz
			# "se: (127512)(1-0)" / "so.en: (127512)(1-0)" - the value of ''127'' comes from the "velocity"-''variable'', ''127 * 512 = 65024'' which is awfully close to a maximum hammer force of 65535. Since no previous notes were held down, the ''"''notecount"-''variable'' is equal to ''0'' and thus ''65024 * 1 = 65024''. The hammer is engaged with near maximum force.
	So the result is that we have set the speed of the ''bowing motor'' and we have engaged the ''hammer''.		So the result is that we have set the speed of the ''bowing motor'' and we have engaged the ''hammer''.

	Now imagine that without releasing this key, we press another 'C' one octave above but at half the velocity. The Ekdahl FAR creates the following ''command string''<pre>		Now imagine that without releasing this key, we press another 'C' one octave above but at half the velocity. The Ekdahl FAR creates the following ''command string''<pre>
	[irq]mev:noteon:'~~m:0,b:0,~~bchb:48,bmr:1,bpid:1,bpe:1,se:(63512)(1-1),bcsm:0'		FAR < 1.1:
	</pre>Now we can see that the ''note'' variable is ''48'' because the 'C' one octave up is exactly 12 keys above the first~~, the~~ ''~~velocity~~'' ~~variable~~ has changed to ''63'' since we hit it with a lighter touch - and because we are <u>still holding the first key down</u> ''~~notecount~~'' is equal to ''1''. Here's what happens		[irq]mev:noteon:'bchb:48,bmr:1,bpid:1,bpe:1,se:(63512)(1-1),bcsm:0'

			FAR 1.1:
			[irq]mcf[0].mc[0].non:'bw.hsh.hb:48,bw.dcm.ru:1,bw.pe:1,bw.bp.en:1,so.en:(65512)(1-1),bw.sm:0'
			</pre>Now we can see that the "note"-''variable'' is 48 because the 'C' one octave up is exactly 12 keys above the first. The "velocity"-''variable'' has changed to 63 since we hit it with a lighter touch - and because we are <u>still holding the first key down</u>, the "notecount"-''variable'' is equal to ''1''. Here's what happens

	# ''bchb: 48'' - Due to the ''base'' being set to ''36'' the ''harmonic number'' is set to ''48 - 36 = 12''. Because we are using a 12-tone scale ''harmonic number 12'' is exactly one octave above the ''fundamental'' thus the speed of the ''bowing wheel'' is set to ''65.4 * 2 = 130.8'' Hertz.		# "bchb: 48" / "hsh.hb:48" - Due to the ''base'' being set to ''36'' the ''harmonic number'' is set to ''48 - 36 = 12''. Because we are using a 12-tone scale ''harmonic number 12'' is exactly one octave above the ''fundamental'' thus the speed of the ''bowing wheel'' is set to ''65.4 * 2 = 130.8'' Hertz.
	# ''se: (63512)(1-1)'' - So ''63 * 512 = 32256'' and ''1 - 1 = 0'' thus ''32256 * 0 = 0''. When the ''~~solenoidengage~~''~~-command~~ gets a ''parameter'' of ''0'' it will not engage the ''hammer'' - so the ''hammer'' doesn't strike		# "se: (63512)(1-1)" / "so.en: (63512)(1-1)" - The equation evalutes as ''63 * 512 = 32256'' and ''1 - 1 = 0'' thus ''32256 * 0 = 0''. When the "solenoidengage" / "solenoid.engage"-''command'' gets a ''parameter'' of ''0'' it will not engage the ''hammer'' - so the ''hammer'' doesn't strike
	So it can be seen that with quite rudimentary math we can accomplish a whole lot of things here. Note also that even though the ''note on MIDI message'' also sets the ''channel''-variable we never use it in this example - plenty of opportunity to make something weird happen depending on the ''MIDI channel''!		So it can be seen that with quite rudimentary math we can accomplish a whole lot of things here. Note also that even though the ''note on MIDI message'' also sets the ''channel''-variable we never use it in this example - plenty of opportunity to make something weird happen depending on the ''MIDI channel''!

Knaadmin at 18:05, 10 June 2026

2026-06-10T18:05:36Z

← Older revision		Revision as of 14:05, 10 June 2026
Line 203:		Line 203:
	Now let's break down what happens when this ''MIDI message'' is received, i.e. when a ''MIDI'' key is pressed down:		Now let's break down what happens when this ''MIDI message'' is received, i.e. when a ''MIDI'' key is pressed down:

	# "bchb:note" / "bw.hsh.hb:note" - Invokes the "bowcontrolharmonicbase" / "harmonicserieshandler.harmonicbase"''-command'' with the first ''parameter'' set to the ''variable note''. This sets the ''base harmonic'' that the Ekdahl FARs ''bowing motor'' should be set to.		# "bchb:note" / "bw.hsh.hb:note" - Invokes the "bowcontrolharmonicbase" / "harmonicserieshandler.harmonicbase"''-command'' with the first ''parameter'' set to the ''variable note''. This sets the ''base harmonic'' that the Ekdahl FARs ''bowing motor'' should be set to. Here the ''variable'' "note" is used which is simply the MIDI key being pressed down, it is automatically converted by the ''command'' to the corresponding harmonic in the ''harmonic list''
	# "bmr:1" / "bw.dcm.ru" - Sets the "bowmotorrun" / "dcmotor.run"-command to '1', starting the ''bow motor''		# "bmr:1" / "bw.dcm.ru" - Sets the "bowmotorrun" / "dcmotor.run"-command to '1', starting the ''bow motor''
	# "bpid:1" / "bw.pe:1" - Sets the "bowpid" / "bowingwheel.pidenable"-''command'' to '1'. Basically this enables the function that makes the Ekdahl FAR able to keep a stable frequency on the ''bowing motor''.		# "bpid:1" / "bw.pe:1" - Sets the "bowpid" / "bowingwheel.pidenable"-''command'' to '1'. Basically this enables the function that makes the Ekdahl FAR able to keep a stable frequency on the ''bowing motor''.
	# "bpe:1" / "bw.bp.en" - Sets the "bowpressureengage" / "bowpressure.engage"-''command'' to '1' which moves the ''bowing jack'' to the ''engage position''		# "bpe:1" / "bw.bp.en" - Sets the "bowpressureengage" / "bowpressure.engage"-''command'' to '1' which moves the ''bowing jack'' to the ''engage position'', aka just below the string if not additional ''pressure'' is applied
	# "se:(velocity512)(1-notecount)" / "so.en:(velocity512)(1-notecount)" - Executes the "solenoidengage" / "solenoid.engage"-''command'' with the value ''(velocity512)(1-notecount)''. This will make the ''solenoid'' strike the ''hammer'' with a force that is dependent on the ''velocity'' variable sent by the ''Note On MIDI message'' in order to make the ''hammer'' velocity sensitive. But it also adds the somewhat perplexing part "*(1-notecount)". "notecount" is a global ''variable'' that contains the number of MIDI keys that are currently being held down. If "notecount" is anything above zero, the outcome of the equation will either be zero or a negative number. The "solenoidengage" / "solenoid.engage"-''command'' requires a ''16-bit unsigned'' value, aka the only valid numbers are 0 - 65535. Anything below 0 will be interpreted as zero, so what this equation does is that it only fires off the ''hammer'' if there are no previous keys being held down - it's ~~going into~~ ''staccato'' mode.		# "se:(velocity512)(1-notecount)" / "so.en:(velocity512)(1-notecount)" - Executes the "solenoidengage" / "solenoid.engage"-''command'' with the value ''(velocity512)(1-notecount)''. This will make the ''solenoid'' strike the ''hammer'' with a force that is dependent on the ''velocity'' variable sent by the ''Note On MIDI message'' in order to make the ''hammer'' velocity sensitive. But it also adds the somewhat perplexing part "*(1-notecount)". "notecount" is a global ''variable'' that contains the number of MIDI keys that are currently being held down. If "notecount" is anything above zero, the outcome of the equation will either be zero or a negative number. The "solenoidengage" / "solenoid.engage"-''command'' requires a ''16-bit unsigned'' value, aka the only valid numbers are 0 - 65535. Anything below 0 will be interpreted as zero, so what this equation does is that it only fires off the ''hammer'' if there are no previous keys being held down - it's being used in ''staccato'' mode.
	# "bcsm:0" / "bowingwheel.speedmode" - Sets the "bowcontrolspeedmode" / "bowingwheel.speedmode" to '1' which enables automatic shut down of the ''bowing motor'' after a given timeout.		# "bcsm:0" / "bowingwheel.speedmode" - Sets the "bowcontrolspeedmode" / "bowingwheel.speedmode" to '1' which enables automatic shut down of the ''bowing motor'' after a given timeout.
	The first two ''commands'' are the ''module''- and ''bow-''command. These ''commands'' are is intended for future versions of the Ekdahl FAR that may contain more than one string or more than one bow per string. For now ''0'' is the only valid ''parameter'' value that will be accepted for either ''command''.''<nowiki/>''

	The ''bowcontrolharmonicbase''-command sets the speed of the ''bowing wheel'' to its corresponding ''harmonic number'' but also takes into account its ''<nowiki/>'base''' which is the ''MIDI key'' that is mapped to ''harmonic number 0''.

	~~After this the bowing motor is started and the ''PID'' is turned, now the instrument will try and make sure that the ''bowing wheel'' is at the right speed.~~

	The ''bowing jack'' is raised to the ''engage position'', any added ''pressure modifiers'' will also be taken into account - once the ''bowing jack'' has reached its intended position the ''bowing wheel'' should (hopefully) make contact with the string and the Ekdahl FAR will start to produce sounds.

	After this we have the ''solenoidengage''-command ''command'' that engages the ''hammer'' and uses the first and only ''parameter'' as the force used. Like with most ''commands'' the ''se''-command is 16-bit (0 - 65535) but the ''MIDI velocity variable'' is 7-bit (0 - 127), so to get the ''velocity'' variable to cover the entire range it needs to be multiplied with 512.

	The ''<nowiki/>'*(1-notecount)'''-part is a way of making sure that we are using ''legato'' mode, i.e. that the ''hammer'' is not triggered if a key is already held down when a new key is pressed. The ''notecount''-variable contains the number of ''MIDI'' notes currently held down.

	Let's postulate that the Ekdahl FAR is tuned to a 'C' at 65.4Hz and has its ''base'' set to middle 'C' (''MIDI key'' no 36). We are using the equal-temperament 12-tone scale and the Ekdahl FAR is set to respond to <u>all</u> ''MIDI channels'' (omni). Without having previously held any keys we press the middle 'C' (''note'' value 36) as hard as possible (''velocity'' value ''127'') on ''MIDI channel'' number 1 (''channel'' value of 0). The Ekdahl FAR will get a ''note on MIDI message'' sent to it and from our mapping it will create the following ''command string''<pre>[irq]mev:noteon:'m:0,b:0,bchb:36,bmr:1,bpid:1,bpe:1,se:(127512)(1-0),bcsm:0'</pre>What has happened here is that all ''variables'' have been replaced with the values sent by the ''MIDI message''. Since those ''commands'' that doesn't have any ''variables'' with them will execute just as previously, only those ''commands'' whos ''parameters'' have changed will be explained:		Let's postulate that the Ekdahl FAR is tuned to a 'C' at 65.4Hz and has its ''base'' set to middle 'C' (''MIDI key'' no 36). We are using the equal-temperament 12-tone scale and the Ekdahl FAR is set to respond to <u>all</u> ''MIDI channels'' (omni). Without having previously held any keys we press the middle 'C' (''note'' value 36) as hard as possible (''velocity'' value ''127'') on ''MIDI channel'' number 1 (''channel'' value of 0). The Ekdahl FAR will get a ''note on MIDI message'' sent to it and from our mapping it will create the following ''command string''<pre>[irq]mev:noteon:'m:0,b:0,bchb:36,bmr:1,bpid:1,bpe:1,se:(127512)(1-0),bcsm:0'</pre>What has happened here is that all ''variables'' have been replaced with the values sent by the ''MIDI message''. Since those ''commands'' that doesn't have any ''variables'' with them will execute just as previously, only those ''commands'' whos ''parameters'' have changed will be explained:

Knaadmin at 17:53, 10 June 2026

2026-06-10T17:53:56Z

← Older revision		Revision as of 13:53, 10 June 2026
Line 14:		Line 14:

	Since version 1.1 of the Ekdahl FAR Firmware, all commands are grouped in a hierarchical fashion according to their ''modules'' and each ladder in the hierarchy is separated by a period ("."), this works very much like folders or directories in a regular computer. Every ''module'' can contain both ''commands'' and other ''modules''. For instance, everything associated with the ''bowing wheel'' is now collected under "bowingwheel" ''module''. That in turn contains a "dcmotor" ''module'' which handles direct control of the bowing motor. It also has a "pid" ''module'' that handles bow frequency among other thing.		Since version 1.1 of the Ekdahl FAR Firmware, all commands are grouped in a hierarchical fashion according to their ''modules'' and each ladder in the hierarchy is separated by a period ("."), this works very much like folders or directories in a regular computer. Every ''module'' can contain both ''commands'' and other ''modules''. For instance, everything associated with the ''bowing wheel'' is now collected under "bowingwheel" ''module''. That in turn contains a "dcmotor" ''module'' which handles direct control of the bowing motor. It also has a "pid" ''module'' that handles bow frequency among other thing.



	If for instance we would like to start the ''bowing wheel'' and set its frequency to 82.5 Hertz we could send the Ekdahl FAR the following ''command string''<pre>FAR < 1.1:		If for instance we would like to start the ''bowing wheel'' and set its frequency to 82.5 Hertz we could send the Ekdahl FAR the following ''command string''<pre>FAR < 1.1:
Line 175:		Line 173:
	</pre>This may return something like<pre>		</pre>This may return something like<pre>
	FAR < 1.1:		FAR < 1.1:
	[irq]mev:pb:"~~bchsh~~:pitch*4"		[irq]mev:pb:"bowcontrolharmonicshift:pitch*4"

	FAR 1.1:		FAR 1.1:
	[irq]bw[0].mcf[0].mc[0].pb:"bowingwheel.harmonicserieshandler.harmonicseries.shift:pitch*4"		[irq]bw[0].mcf[0].mc[0].pb:"bowingwheel.harmonicserieshandler.harmonicseries.shift:pitch*4"
	</pre>The first part of the return message tells us that the incoming message is of "rqi"-type ("[irq]") which means it's responding to a information request ''command'' sent. The second part tells us what ''command'' the ~~data pertains~~ to, and any ''parameters'' that may be pertinent. The third part of the message is the actual data stored.		</pre>The first part of the return message tells us that the incoming message is of "rqi"-type ("[irq]") which means it's responding to a information request ''command'' sent. The second part tells us what ''command'' the information request return is responding to and any ''parameters'' that may be pertinent. The third part of the message is the actual data stored.

	For the FAR < 1.1 the data returned is for the ''command'' "mev" with the first ''parameter'' set to "pb", the ''command reference'' tells us this means the ''command'' "midieventhandler" and the ''parameter'' "pb" indicates this has to do with the ''pitch bend''. The data is "~~bchsh~~*4".		For the FAR < 1.1 the data returned is for the ''command'' "mev" with the first ''parameter'' set to "pb", the ''command reference'' tells us this means the ''command'' "midieventhandler" and the ''parameter'' "pb" indicates this has to do with the ''pitch bend''. The data is "bowcontrolharmonicshift*4".

	For the FAR 1.1 the data returned is for the ''command'' "bw[0].mcf[0].mc[0].pb" (bowinwheel[0].midiconfigurationhandler[0].midiconfiguration[0].pitchbend) and the data is "bowingwheel.harmonicserieshandler.harmonicseries.shift:pitch*4". Note here that if we have several different ''MIDI configurations'' stored and we're currently using configuration number 2, the returned message would have been "bw[0].mcf[0].mc[2].pb".		For the FAR 1.1 the data returned is for the ''command'' "bw[0].mcf[0].mc[0].pb" (bowinwheel[0].midiconfigurationhandler[0].midiconfiguration[0].pitchbend) and the data is "bowingwheel.harmonicserieshandler.harmonicseries.shift:pitch*4". Note here that if we have several different ''MIDI configurations'' stored and we're currently using configuration number 2, the returned message would have been "bw[0].mcf[0].mc[2].pb".

	that the ''pitch bend MIDI message'' is executing a "~~bchsh~~" / "-command with the parameter ''pitch*4''. Looking in the ''command reference'' we can see that ''~~bchsh~~'' ~~is the~~ ''~~short name~~'' ~~of the ''bowcontrolharmonicshift''-command which~~ shifts the frequency of the ''bowing wheel'' from the ~~current frequency, the~~ first (and only) parameter sets how much we want to shift it (depends on the ''~~bowcontrolharmonicshiftrange~~ command'').		that the ''pitch bend MIDI message'' is executing a "bowcontrolharmonicshift" / "harmonicseries.shift"-command with the parameter ''pitch*4''. Looking in the ''command reference'' we can see that ''"''bowcontrolharmonicshift" / "harmonicseries.shift"-''command'' shifts the frequency of the ''bowing wheel'' from the currently selected harmonic. The first (and only) ''parameter'' sets how much we want to shift it (the range depends on the "bowcontrolharmonicshiftrange''"'' / "harmonicseries.shiftrange"-''command'').

	If we look in the list of ''[[The Ekdahl FAR - Command langue#Variables\|variables]]'' above we can see that the ''pitch bend MIDI message'' will set the ''~~pitch~~ variable'' which is indeed used. Now what is the '''*4''<nowiki/>' all about? Well the ''~~bchsh~~''~~-command~~ expects a ''16-bit signed'' value~~, meaning~~ that a full ''harmonic shift'' downwards is equal to -32767, a full ''harmonic shift'' upwards is 32767 and no ''harmonic shift'' is 0. The ''pitch bend MIDI message'' however is only 14-bits, meaning its range is -8192 to 8192~~, so in order to be able to use the entire range~~ we have to multiply ''pitch'' by 4.		If we look in the list of ''[[The Ekdahl FAR - Command langue#Variables\|variables]]'' above we can see that the ''pitch bend MIDI message'' will set the "pitch"''-variable'' which is indeed used. Now what is the '''*4''<nowiki/>' all about? Well the "bowcontrolharmonicshift" / "harmoniceseries.shift"-''command'' expects a ''16-bit signed'' value as its ''parameter''. This means that the valid ''parameter'' number can be anything from -32767 to 32767. A full ''harmonic shift'' downwards according to the range set is equal to -32767, a full ''harmonic shift'' upwards is 32767 and no ''harmonic shift'' is 0. The ''pitch bend MIDI message'' however is only 14-bits, meaning its range is -8192 to 8192. So we have to multiply ''pitch'' by 4 in order to meet the requirements of a ''16-bit signed parameter''.

	This whole thing about number of bits can seem confusing but in the end it's all about how fine control you have over things; the more possible values, the more detailed control. In fact, most ''MIDI'' values are only 7-bit (!) meaning a range of 0 - 127. While this may sound like a lot of detail for something like a volume control, it is not even close to enough resolution to for instance set the ''bowing ~~speed~~''. ~~Imagine that our lowest possible note frequency is 50 Hz, that means that with~~ a ~~0-127 range we can only go from 50 Hz to 127 + 50 = 177 Hz - and with no decimals! This meager range and the very coarse steps of only 1 Hz would mean~~ the instrument would never be able to ~~sound~~ in tune ~~and wouldn't even have two octaves of range~~. The idea of limiting the Ekdahl FAR to what is possible through ''MIDI'' seemed like a poor choice thus it was decided that <u>most</u> parameters will instead be 16-bit.		This whole thing about number of bits can seem confusing but in the end it's all about how fine control you have over things; the more possible values, the more detailed control. In fact, most ''MIDI'' values are only 7-bit (!) meaning a range of 0 - 127. While this may sound like a lot of detail for something like a volume control, it is not even close to enough resolution to for instance set the ''bowing frequency''. Even if you would limit yourself to a single octave the instrument would never be able to be properly in tune. The idea of limiting the Ekdahl FAR to what is possible through ''MIDI'' seemed like a poor choice thus it was decided that <u>most</u> parameters will instead be 16-bit.

	Now lets look at a more complex example, the <u>default</u> ''Note On MIDI message''. On a stock Ekdahl FAR, executing<pre>		Now lets look at a more complex example, the <u>default</u> ''Note On MIDI message''. On a stock Ekdahl FAR, executing<pre>
			FAR < 1.1:
	rqi:mev:noteon		rqi:mev:noteon
	</pre>Will return something like<pre>[irq]mev:noteon:'~~m:0,b:0,~~bchb:note,bmr:1,bpid:1,bpe:1,se:(velocity512)(1-notecount),bcsm:0'</pre>As can be seen, there's a lot of stuff going on here! First of all, notice that everything after ''mev:noteon:'' is situated in between single quotes (') - this is <u>absolutely crucial</u> for the Ekdahl FAR to know that everything within those last two quotes is part of the last ''parameter'' of the ''~~mev~~''~~-command~~.
			FAR 1.1:
			rqi:mcf.mf.non
			</pre>Will return something like<pre>FAR < 1.1:
			[irq]mev:noteon:'bchb:note,bmr:1,bpid:1,bpe:1,se:(velocity512)(1-notecount),bcsm:0'

			FAR 1.1:
			[irq]mcf[0].mc[0].non:'bw.hsh.hb:note,bw.dcm.ru:1,bw.pe:1,bw.bp.en:1,so.en:(velocity512)(1-notecount),bw.sm:0'</pre>As can be seen, there's a lot of stuff going on here! First of all, notice that everything after "mev:noteon:" / "mcf[0].mc[0].non:" is situated in between single quotes (') - this is <u>absolutely crucial</u> for the Ekdahl FAR in order to know that everything within those last two quotes is part of the last ''parameter'' of the "mev" / "mcf.mc.non"-''command''.

	Now let's break down what happens when this ''MIDI message'' is received, i.e. when a ''MIDI'' key is pressed down:		Now let's break down what happens when this ''MIDI message'' is received, i.e. when a ''MIDI'' key is pressed down:

	# ~~''m~~:0'' - ~~Sets~~ ''~~module~~'' ~~to 0~~		# "bchb:note" / "bw.hsh.hb:note" - Invokes the "bowcontrolharmonicbase" / "harmonicserieshandler.harmonicbase"''-command'' with the first ''parameter'' set to the ''variable note''. This sets the ''base harmonic'' that the Ekdahl FARs ''bowing motor'' should be set to.
	~~# ''b:0'' - Sets ''bow~~'' to 0		# "bmr:1" / "bw.dcm.ru" - Sets the "bowmotorrun" / "dcmotor.run"-command to '1', starting the ''bow motor''
	# ''~~bchb:~~note'' ~~- Invokes~~ the ''~~bowcontrolharmonicbase-~~''~~command with~~ the ~~first~~ ''~~parameter~~'' set to ~~the ''variable note''~~.		# "bpid:1" / "bw.pe:1" - Sets the "bowpid" / "bowingwheel.pidenable"-''command'' to '1'. Basically this enables the function that makes the Ekdahl FAR able to keep a stable frequency on the ''bowing motor''.
	# ''bmr:1'' - Sets the ''bowmotorrun''-command to '1', starting the ''bow motor''		# "bpe:1" / "bw.bp.en" - Sets the "bowpressureengage" / "bowpressure.engage"-''command'' to '1' which moves the ''bowing jack'' to the ''engage position''
	# ''bpid:1'' - Sets the ''~~bowpid~~''~~-command~~ to '1'~~, making sure~~ the ''~~PID~~'' ~~is used~~		# "se:(velocity512)(1-notecount)" / "so.en:(velocity512)(1-notecount)" - Executes the "solenoidengage" / "solenoid.engage"-''command'' with the value ''(velocity512)(1-notecount)''. This will make the ''solenoid'' strike the ''hammer'' with a force that is dependent on the ''velocity'' variable sent by the ''Note On MIDI message'' in order to make the ''hammer'' velocity sensitive. But it also adds the somewhat perplexing part "*(1-notecount)". "notecount" is a global ''variable'' that contains the number of MIDI keys that are currently being held down. If "notecount" is anything above zero, the outcome of the equation will either be zero or a negative number. The "solenoidengage" / "solenoid.engage"-''command'' requires a ''16-bit unsigned'' value, aka the only valid numbers are 0 - 65535. Anything below 0 will be interpreted as zero, so what this equation does is that it only fires off the ''hammer'' if there are no previous keys being held down - it's going into ''staccato'' mode.
	# ''bpe:1'' - Sets the ''~~bowpressureengage~~'' to '1' which moves the ''bowing jack'' to the ''engage position''		# "bcsm:0" / "bowingwheel.speedmode" - Sets the "bowcontrolspeedmode" / "bowingwheel.speedmode" to '1' which enables automatic shut down of the ''bowing motor'' after a given timeout.
	# ''se:(velocity512)(1-notecount)'' - Executes the ''~~solenoidengage~~''~~-command~~ with the value ''(velocity512)(1-notecount)''
	# ''~~bcsm:~~0'' - ~~Sets the~~ ''~~bowcontrolspeedmode~~'' to '1' which enables automatic shut down of the ''bowing motor''
	The first two ''commands'' are the ''module''- and ''bow-''command. These ''commands'' are is intended for future versions of the Ekdahl FAR that may contain more than one string or more than one bow per string. For now ''0'' is the only valid ''parameter'' value that will be accepted for either ''command''.''<nowiki/>''		The first two ''commands'' are the ''module''- and ''bow-''command. These ''commands'' are is intended for future versions of the Ekdahl FAR that may contain more than one string or more than one bow per string. For now ''0'' is the only valid ''parameter'' value that will be accepted for either ''command''.''<nowiki/>''

Knaadmin at 18:17, 8 June 2026

2026-06-08T18:17:41Z

Show changes

Knaadmin at 15:06, 8 June 2026

2026-06-08T15:06:37Z

← Older revision		Revision as of 11:06, 8 June 2026
Line 140:		Line 140:

	'''FAR < 1.1:'''		'''FAR < 1.1:'''
	~~<pre>~~
	The ''command'' responsible for mapping ''command strings'' to different ''MIDI messages'' is ''midieventhandler'' or ''mev'' for short. The first ''parameter'' of ''mev'' is the type of ''MIDI message'' that we want to remap

	* '''''~~noteon~~''''' - Note on		'''FAR < 1.1'''
	* '''''noteoff''' -'' Note off
	* '''''pat''' -'' Poly after touch		The ''command'' responsible for mapping ''command strings'' to different ''MIDI messages'' is 'midieventhandler' or 'mev' for short. The first ''parameter'' of 'mev' is the type of ''MIDI message'' that we want to remap
	* '''''cat''''' - Channel after touch
	* '''''pb''''' - Pitch bend		* '''noteon''' - Note on
	* '''''pc''''' - ~~Program change~~		* '''noteoff''' - Note off
	* '''''cc''''' - ~~Continuous controller~~		* '''pat''' - Poly after touch
			* '''cat''' - Channel after touch
			* '''pb''' - Pitch bend
			* '''pc''' - Program change
			* '''cc''' - Continuous controller

			The second ''parameter'' is the ''command string'' that is to be associated with the ''MIDI Message'' - with the exception of the '''cc'''-type, here the second ''parameter'' is the ''controller number'' (0 - 127) and the third ''parameter'' is the ''command string''.

	The ~~second~~ ''~~parameter~~'' ~~is the~~ ''command ~~string~~'' ~~that is~~ to ~~be associated with~~ the ''MIDI ~~Message~~'' - ~~with~~ the ~~exception of~~ the ''cc''-~~type, here~~ the ~~second~~ ''~~parameter~~'' ~~is the~~ ''~~controller number~~'' (0 - ~~127) and~~ the ~~<u>third<~~/u> ''~~parameter~~'' is the ''~~command string~~''.		'''FAR 1.1'''
	</~~pre>~~
			The ''commands'' responsible for mapping ''command strings'' to different ''MIDI messages'' are as follows

			* '''noteon/non''':''commands'' - Sets the ''commands'' executed for a 'note on' ''MIDI message''
			* '''noteoff/nof''''':commands'' - Sets the commands executed for a 'note off' ''MIDI message''
			* '''polyaftertouch/pat''''':commands'' - Sets the commands executed for a 'poly aftertouch' ''MIDI message''
			* '''channelaftertouch/cat''''':commands'' - Sets the commands executed for a 'channel aftertouch' ''MIDI message''
			* '''pitchbend/pb''''':commands'' - Sets the commands executed for a 'pitch bend' ''MIDI message''
			* '''programchange/pc''''':commands'' - Sets the commands executed for a 'program change' ''MIDI message''
			* '''continuouscontrollerdata/ccd''''':controller:commands'' - Sets the ''commands'' executed for 'continuous controller' no ''controller''

	~~<pre>~~
	~~'''FAR 1.1:'''~~

	~~The ''commands'' responsible for mapping ''command strings'' to different ''MIDI messages'' are as follows~~

	* '''noteon/non''''':commands'' - Sets the commands executed for a ''note on'' ''MIDI message''
	* '''noteoff''/nof'''''<nowiki/>'':commands'' - Sets the commands executed for a ''note off MIDI message''
	* '''polyaftertouch/pat''''':commands'' - Sets the commands executed for a ''poly aftertouch MIDI message''
	* '''channelaftertouch/cat''''':commands'' - Sets the commands executed for a ''channel aftertouch MIDI message''
	* '''pitchbend/pb''''':commands'' - Sets the commands executed for a ''pitch bend MIDI message''
	* '''programchange/pc''''':commands'' - Sets the commands executed for a ''program change MIDI message''
	* '''continuouscontrollerdata/ccd''''':controller:commands'' - Sets the commands executed for ''continuous controller'' no ''controller''
	~~</pre>~~

	We can of course use the ''rqi''-command to check the current mapping, below we are asking what the current ''command string'' associated with the ''pitch bend'' ''MIDI message'' is<pre>		We can of course use the ''rqi''-command to check the current mapping, below we are asking what the current ''command string'' associated with the ''pitch bend'' ''MIDI message'' is<pre>