Recent Posts

Pages: [1] 2 3 ... 10
1
PreenFM2 / Re: midi channel for combo program change
« Last post by lokki on July 27, 2017, 05:17:03 PM »
ok i will attempt this myself, seems straightforward. i already have a version with hardcoded midichannel 1 for general modulation.

xavier, can you tell me where in the code i find the global menu? so i can try and add the value there.
2
PreenFM2 / midi channel for combo program change
« Last post by lokki on July 27, 2017, 12:02:21 AM »
what is the midi channel for program change?

 is it just the first midi channel set in the menu?

it would be great if there was a global midi channel setting, that can receive program change and is independent from the settings of the instruments. (so for example instruments set to channel 2 to 5 and global midi channel 1)

also to think things further, it would be great if general cc messages could also arrive on the global channel and be spread to the four instruments. (for example, breath control on channel 1 would be applied to all 4 instruments)

this would decrease the midi messages you have to send and would also comply somewhat with the new mpe midi standard.

3
PreenFM2 / PreenFM2 is sending me NRPN dumps four times in row
« Last post by feijai on July 26, 2017, 05:43:30 PM »
 :o

I have identified a strange and very frustrating bug in the PreenFM2's response over USB MIDI. 

When my program (written in Java) sends a single NRPN 127/127 (data=1) over USB MIDI, most of the time my PreenFM2 box responds with *four* identical NRPN parameter dumps.  I've been spying on the MIDI data results using MIDI Monitor and have verified that only a single NRPN request is being made.  This is frustrating because the pfm2Editor doesn't seem to trigger this even though it's sending the same exact data.

Making things even weirder, when you connect the PreenFM2 over USB MIDI (on OS X, I'm running 10.9.5) it sets up a virtual connection TO ITSELF, so it's routing its own NRPN data back to itself, which is definitely not right.

I have also tried talking to the PreenFM over 5-pin DIN MIDI using a USB MIDI interface (a Tascam US-2x2).  This works perfectly: I always get back one NRPN parameter dump per request of my program.  The Tascam also does not set up a virtual connection to itself (nor do other devices, such as my Blofeld, BeatStep, or MicroSampler).

This tells me that with a fairly high probability there is a bug in the PreenFM2's USB MIDI driver or its behavior when over USB MIDI; because there is no difference between my MIDI stream and pfm2Editor: the only difference is that they have different USB MIDI labels.  And further, the PreenFM2 behaves correctly over 5-Pin DIN.

This is a really frustrating bug.
4
PreenFM2 / Revised PreenFM2 MIDI page
« Last post by feijai on July 26, 2017, 03:09:00 PM »
From the HTML it looks like this page is generated dynamically.  But I have edited it to include everything I have determined about the actual ranges and values of the various NRPN inputs.  I hope this is helpful.
5
PreenFM2 / Re: NRPN and MIDI documentation questions and issues part 3
« Last post by feijai on July 26, 2017, 11:14:26 AM »
The preenfm2 expectes NRPN messages (not RPN).

Looking through the code solves the mystery of why Arpeggiator Pattern and Arpeggiator Direction aren't working.  And it's not a good result.  :-( :-(

The CC for these two (CC_ARP_PATTERN, CC_ARP_DIVISION) is 100 and 101, the two values for RPN.  This means that if I send an RPN NULL, the PreenFM2 is presently interpreting it as changing the ARP pattern and ARP division (to 127!).

This is a problem.  The industry best practice for NRPN is to send an NRPN message and then terminate it with an RPN NULL to make sure it's closed.  See here for an example:  http://www.philrees.co.uk/nrpnq.htm   Various controllers (including ones I've built) follow this practice.  This means that the PreenFM2 can't be used with these controllers.  If a synth handles NRPN, it also has to handle RPN at least enough to deal with RPN NULL.

There are some other problems with the NRPN handler: it's not properly parsing NRPN messages.  The PreenFM2 requires you to submit 38 (LSB) even though that's not an NRPN requirement.  Also you can't send a 38 first, then a 6 (which is also valid).   And it doesn't handle running status, so you can't send a stream of 6 or 38.  And I think you can interrupt an NRPN message with another random CC and it doesn't invalidate the NRPN message.

The Preen is presently doing this:

Code: [Select]
If I received a 99 then update paramMSB
Else if I received a 98 then update paramLSB
Else if I received a 6 then update MSB
Else if I received a 38 then
    update LSB
    Do(current param, current value)
Else if I receive anything else then
    process it (but don't clear out the paramMSB, paramLSB, MSB, or LSB!)

The problem is that this is not stateful, so it has some problems.  My C++ foo is not good but I might try to submit a patch which could fix things (it probably won't compile but it would give you an idea of what to do).  I probably won't be able to enable running status or allowing just a 6 or 38, because in order to do that you have to change the preen's parameters every time a 6 *or* 38 is received, not wait for both of them.

In general, if you don't want your device to have to pause to wait for an (optional) additional 6 or 38, then NRPN works as follows.

Code: [Select]
If I received a 99 then
    If I received a 98 then
        MSB = 0, LSB = 0
        Loop
            If I received a 6 then
                Update MSB
                Do(param, MSB, LSB)
            Else if I received a 38 then
                Update LSB
                Do(param, MSB, LSB)
            Else if I received anything else then
                push back into the CC stream
                break from loop
    Else if I received anything else then
        push back into the CC stream

This pseudocode is easy but requires you to do partial updates with just the MSB or just the LSB (unfortunately, NRPN permits this).  Your other option is to wait for a little bit to see if the LSB is coming next and then update, but this could slow down NRPN parsing slightly.

Some controllers send both LSB and MSB, but others (like the BeatStep series) only send LSB or only send MSB.  And the order is not guaranteed.  I think what should be done is to expect both MSB and LSB, but then continue to update single LSB or MSB updates on running status.  And if you want to do NRPN, I think you really HAVE to reserve 100 and 101 for RPN or it won't work with certain controllers.  This means moving or deleting arpeggiator direction and pattern.

This still doesn't solve the mystery of why sending CC 101 or CC 100 causes the PreenFM2 to slow down (a lot -- like 1 MS).
6
PreenFM2 / Re: NRPN and MIDI documentation questions and issues part 2
« Last post by feijai on July 26, 2017, 10:36:39 AM »
As you noticed, the preenfm2 it not NRPN proof, sending wrong value can crash it.

Well the critical bug is #3: you can't set the Arpeggiator Pattern or Pattern Direction at all via NRPN.  It's broken.

Quote
9. for freq >= 1.0 the increment/decrement is set to 0.1.

I think the logic should be: (incrementing ? (x >= 1.0 ?  0.1 : 0.01) : (x <= 1.0 ? 0.01 : 0.1))

Quote
11. The number of voice is supposed to be the number of voices saved with the preset. Or if the other instruments have voices that prevent this number to be set for the newly loaded preset.

I would like to agitate to have an option where the behavior is instead: if the voice has a preset of 1, use 1.  Else the number of voices should be all remaining available voices not currently allocated.  I believe this behavior would be helpful to a large majority of users.

Quote
12. Not sure i understand. Saving sysex dump all current instrument parameteres. Combo are the 4 instruments saved at the same time.

My belief of the sysex dump was that it dumped out the entire memory state.  But now I don't know.  Is the sysex dump for a Bank just the state for a single instrument?  If so, what is the format the Combo dump?  Does it concatenate four Bank dumps, and if it does now does it specify which one is which instrument?  These two can't be the same.
7
PreenFM2 / Re: NRPN and MIDI documentation questions and issues
« Last post by Xavier on July 25, 2017, 10:44:36 PM »
Quote from: feijai
I'm confused by this.  Each of the step sequencers has a gate, which is an available destination for modulation.  But there is also the "Gate" destination.  Where does this go?  How does it differ from the step sequencer gates?  Is it documented somewhere?
Also, what is O*Fh?  It also doesn't appear to be documented.

Both step sequencers has a gate. But the gate effect is a totally different gate.
It an internal effect in serial with the LH/BP... effect.
Try to play with it, you'll understand.

Docs needs to be updated for O*fh : explanation is currently here
http://ixox.fr/forum/index.php?topic=63505.0
New in firmware 2.05

Quote from: feijai
17. All clickable encoders are connected to the same digital in... So they cannot have different behaviour.
:-(  There were many opportunities there.  :-(

PCB/hardware limit.

Xavier
8
PreenFM2 / Re: NRPN and MIDI documentation questions and issues part 2
« Last post by Xavier on July 25, 2017, 10:38:17 PM »
As you noticed, the preenfm2 it not NRPN proof, sending wrong value can crash it.

7.8. I unlinked the order in the preenfm2 UI and the internal value. preenfm2 had many firmware upgrades which saw new parameters, some parameters needed a new internal value but had to be inserted in the existing list.
https://github.com/Ixox/preenfm2/blob/master/src/synth/SynthState.cpp#L272

9. for freq >= 1.0 the increment/decrement is set to 0.1.

10. agreed.

11. The number of voice is supposed to be the number of voices saved with the preset. Or if the other instruments have voices that prevent this number to be set for the newly loaded preset.

12. Not sure i understand. Saving sysex dump all current instrument parameteres. Combo are the 4 instruments saved at the same time.

9
PreenFM2 / Re: NRPN and MIDI documentation questions and issues part 3
« Last post by Xavier on July 25, 2017, 10:23:30 PM »
But if I send a properly nulled NRPN(+RPN) message, that is, one of the form: 99, 98, 6, 38, 101(127), 100(127)

Then the PreenFM2 cannot parse faster than about 1ms per message, and starts dropping MIDI bytes if I send faster than that.  :-( :-(  That's not good, it should never be dropping any MIDI bytes ever.  And it means I can't send a nulled message.

The preenfm2 expectes NRPN messages (not RPN).
It expects 99 and 98 to be sent.
Then :
. 6 AND 38
. or 96
. or 97
You can see the code here :
https://github.com/Ixox/preenfm2/blob/master/src/midi/MidiDecoder.cpp#L550

Don't hesitate to submit patch if you modify the code and think you improved the behaviour.

Thanks,

Xavier
10
PreenFM2 / Re: NRPN and MIDI documentation questions and issues part 3
« Last post by feijai on July 25, 2017, 08:53:25 PM »
Another oddity.  The valid characters with which you can make a name appear to include space (' ') twice: once after 'Z' and once after 'z' when you scroll the leftmost encoder when choosing a filename.  Is this the same character and just an oddity of the UI, or are they different characters being represented in the same way?
Pages: [1] 2 3 ... 10