Messages

16

preenfm2 and preenfm3 / Re: PreenFM2 is sending me NRPN dumps four times in row

« on: July 29, 2017, 05:05:10 PM »

I am rescinding this bug report.  Though I could get it to reproduce reliably the whole day under many circumstances, the next day (and on) I have not seen the error again.  So I am going to assume for now that it was an operating system problem.  But if it comes back I'll try to find a repeatable example.

17

preenfm2 and preenfm3 / PreenFM2 is sending me NRPN dumps four times in row

« on: July 26, 2017, 05:43:30 PM »

 

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.

18

preenfm2 and preenfm3 / Revised PreenFM2 MIDI page

« 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.

19

preenfm2 and preenfm3 / Re: NRPN and MIDI documentation questions and issues part 3

« 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).

20

preenfm2 and preenfm3 / Re: NRPN and MIDI documentation questions and issues part 2

« 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.

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))

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.

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.

21

preenfm2 and preenfm3 / Re: NRPN and MIDI documentation questions and issues part 3

« 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?

22

preenfm2 and preenfm3 / Re: NRPN and MIDI documentation questions and issues

« on: July 25, 2017, 05:01:08 PM »

2. sin ^2 : sin*sin.
szer : sin on the first half of the period then zero.
spos : sin always positive.

I see.  These are some of the TX81Z wave shapes, though the TX81Z has a few more too, which might be good to have.  Maybe we can get the PreenFM2 to do LatelyBass.

3. I have to double check that but I assume you can set upper value for user waveform.

Should I be calling them User1...User6 in my patch editor then maybe?

4. The NRPN conversion is a generic. So most of the time it's 0.01 * NRPN value.

I found quite a few gotchas when going through this by hand.  I might be able to revise that page and send it to you.

6. Preenfm2 arpegiator is from mutable instrument open source code. So have a look at the manual :
https://mutable-instruments.net/archive/midipal/manual/

Actually, the Midipal manual only lists up, down, up-down, and random.  I know what chord is; that's why I'm wondering what the others do (Rotate-... and Shift-...)

8.Gate is the gate internal effect. It's an additional effect that is interesting to use with the 2 step sequencers.

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.

17. All clickable encoders are connected to the same digital in... So they cannot have different behaviour.

:-(  There were many opportunities there.  :-(

19. Do they send any value ?

No, they're sending zero.  I worked out what the Note Scaling NRPN parameters were.

23

preenfm2 and preenfm3 / NRPN and MIDI documentation questions and issues part 3

« on: July 25, 2017, 04:44:52 PM »

[I see you're moving the messages, so I'll do the same here to save you time. :-)]

I've found a significant problem with NRPN/RPN parsing.  :-(  In my testing, it appears that the PreenFM2 cannot accept RPN messages at full speed (31500 bps).  I have only tested over USB.

If I send an NRPN message of the form: 99, 98, 6, 38

It seems to be able to parse it in time.

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.

I suspect what's happening is that the PreenFM2's NRPN/RPN parser expects to see a 6 or 38 (or an INC or DEC) after the opening 99/98 or 101/100, and if it doesn't it might be freaking out.  But NRPN and RPN doesn't have to send a 6 or 38; RPN NULL is an example.  Anyway, that's a guess.

24

preenfm2 and preenfm3 / NRPN and MIDI documentation questions and issues part 2

« on: July 24, 2017, 11:39:15 PM »

While cleaning up my editor, I have found the following bugs in the PreenFM2 or in the official patch editor.  They vary from the serious to the minor.  Again, I am using PreenFM2 Firmware 2.07 and pfm2 editor 2.00.


1. Sending NRPN to change the voice count to > 14 crashes the synth.

2. Go to arpeggiator menu when the clock is OFF. Turn it to Int or Ext.  Change the Latch, Dirction, or *especially* Pattern via NRPN, and crazy things happen on the screen.  Lots of japanese characters.  For example: boot the synth.  Go to arpeggiator.  Set to "Internal".  Immediately try to set Pattern via NRPN.

3. Often when the synth receives an Arpeggiator Pattern or Arpeggiator Division NRPN request, it always goes to the maximum value (User 4, or 1/96).  For example: boot the synth.  Go to arpeggiator.  Set to "Internal".  Go to the next page.  Then try to set Pattern via NRPN.

4. The Operator Frequency as displayed in the synth is often 0.01 off of what is displayed on the PreenFM2 editor.

5. The Fixed Operator Frequency (+/- fine tune) is 1 off of what was provided via NRPN about half the time. Perhaps a rounding error?

6. Changing the Operator Fixed/Keyboard flag via NRPN does not refresh the screen for the frequency and fine tune.

7. Modulation sources via NRPN are not in the same order that they're displayed on-screen.  The order of the final seven sources (in NRPN) is Note 1, P1, P2, P3, P4, Note2, Breadth.

8. Modulation destinations are not in the same order that they're displayed on-screen.  The order of the final 14 destinations (in NRPN) is Rel*, mx1, 2, 3, 4, l1fq, 1, 2, e2si, s1ga, 2, Fltr, o*Fh, Dec*.  Still not sure what o*Fh, Gate, or Dec* are :-(.

9. If you're at 1.00 in LFO frequency, and you turn the encoder one step to the left, you don't go to 0.99.  You go to 0.90.


Also a few final brain-dumps and I'm out of stuff:

10. Writing an editor would very much benefit from a single new NRPN command: to write the current edited changes of Instrument 1 to permanent patch memory.  Without it, I think the only way you can save NRPN changes to patch memory is by manually going through the menus on the device.  :-(

Ideally you would encode the Bank and Number as part of the command.  Without encoding them (just having a simple "write" command) you could still implement a write (Bank Change, PC, NRPN dump, Write) but it'd be a little dangerous if the PC and Bank Change weren't received correctly.  It'd be better to do NRPN dump, followed by Write-to-Bank-and-number.

Another useful command would be NRPN Bank and Number Query (and response).

11. When you load an instrument, it often loads with a less than maximal number of voices.  For example, loading with only 6 voices even though 8 are available.  In this day and age of DAWs, multitimbralism is an increasingly rare use case: the vast majority of use of the PreenFM2, I'd wager, is a single sound, with the other instruments set to 0 voices.  In this majority scenario, you always would want to allocate every voice available.  The only exception would be sounds meant to be monophonic, with glide.  I would ask that you consider changing this behavior.

12. How does the sysex format for the "Bank" sounds differ from that of the "Combo" sounds?

25

preenfm2 and preenfm3 / NRPN and MIDI documentation questions and issues

« on: July 23, 2017, 09:05:32 PM »

I am building an open source patch editor for the PreenFM2 in Edisyn.  Yes, I know that Xavier's already exists: but I'm building mine to ultimately do some interesting FM research.  Plus reinventing the wheel is fun.

As I have been building it, I have discovered some documentation errors and one possible error in the standard patch editor; plus I have a number of questions I was hoping someone might clarify for me.  Note that I am using version 2.0.0 of the PreenFM2 Editor (OS X), and Firmware 2.07 (and sadly, my brand new PreenFM2 is R5c, not R5d).

Here we go.

1. I am confused by the maximum number of voices.  The documentation says:

Knowing that 48 operators can be played real time that means that maximum value of voices is :
. 14 voices for 3 operators algorithm
. 12 voices for 4 operators algorithm
. 8 voices for 6 operators algorithm

However, the NRPN documentation states that 16 voices is the maximum value.  This would make sense as 16 * 3 = 48.  But my playing with the PreenFM2 suggests that 14 is in fact the limit  Could you clarify this?


2. Could you tell me what the full name is for the following shapes.  Also, could you describe what they look like?

   s^2    (or sine^2)
   szer   (or "Sine Zero")
   spos   (or "Sine Pos")

Also, "Off" is confusing.  The patch editor assigns "Off" to NRPN value 7, but "Off" appears at position *0* in the PreenFM2 UI.


3. The current firmware permits 14 shapes including the user shapes and "off".  But the NRPN documentation specifies only 8 shapes; and the patch editor only permits 8 shapes.  Could you clarify this?


4. The max value of the Frequency is missing in the NRPN list.  Is it 192?  Also the max value of Fine Tune is also missing.  Is it 200?  Indeed, there are many missing max values and documentation which doesn't map numerical values to underlying meanings.  I've done my best to figure out the mapping, but it's been slow going.  It'd be nice if this was updated.

5. I am inexperienced in coding for FM: but in addition to ADSR, I have often found an initial delay to be a useful item in an envelope.  I know that free envelope 2 has delay (which it calls "silence") -- but having it as an option in the operator envelopes would be nice.

6. Could you describe the following PreenFM Arpeggiator direction options?  [I tried checking the MidiPal arpeggiator manual -- I think the PreenFM2 Arpeggiator may be based on MidiPal? -- but it only has up, down, random, and chord].  Specifically:

   Rotate Up, Rotate Down, Rotate Up-Down
   Shift Up, Shift Down, Shift Up-Down

[BTW, I wrote an arpeggiator for Gizmo, an arduino tool I built a while ago (http://cs.gmu.edu/~sean/projects/gizmo/), and one thing I found more useful in the "Rand" direction was to try hard not to play the same not twice in a row; unless there's only one or two notes.  I think it sounds better that way.  Try it!]

7. There are three undocumented modulation sources in the modulation section. 

   Brth   [Breath controller maybe?]
   Seq 1   [mentioned later in Sequencer section]
   Seq 2   [Likewise]

8. It appears that the PreenFM2 editor software is missing two modulation destinations which are on the machine:  Dec* and O*Fh Is the first "All Operator Decays"?  No idea what O*Fh would be. I think there might possibly be an error in the patch editor.

Also Dec*, O*Fh, and Gate are not documented in the manual.  Can you tell me what they are in this context?

9. The LFO Shape NRPN row says its maximum value is 164.  But there are only 5 shapes.

10. I think there are 339 LFO Frequency values, but it's not clear what the mapping is.  Is Value 0 mapped to Frequency = 0.01?  Etc.  Similarly, what is the mapping for LFO Key Sync?  Is 0=OFF, and 1=0.00, and 2=0.01, etc., up to 1601=16.00?

11. Is LFO Phase=1.00 the same thing as LFO Phase=0.00?  [I presume phase=n means n/100*360 degrees]

12. The NRPN documentation says that step sequencer steps can be 0<=n<=16.  I think this is supposed to say 0<=n<16?

13. Does "_" in the step sequencer mean 0 in the UI?  Why not say "0"?

14. The patch editor has options for "Note1 Scaling" and "Note2 Scaling".  But it appears that these are not documented on the NRPN web page.

15.  The patch editor (and various locations in the manual) uses the French word "Enveloppe" rather than "Envelope".

16. [deleted -- I was wrong on this one]

17. At present the clickable encoders all go to the user parameters page.  I am thinking about other uses for them in the GUI.  For example, one possible use might be to reset their respective parameter back to its default value, or to the value prior to changing it.  For example, if the BPM was 120 and I changed it to 170, clicking the encoder would change it back to 120 and clicking again would go back to 170.

18. The PreenFM2 manual states that the "The envelope of each operator has 8 parameters, copied from the DX7 enveloppe."  In the DX7 operator envelope (see Page 15 of this document) "Level 4" (what the PreenFM2 calls "Release Level") is the level at both the beginning and the end of the envelope.  However in the PreenFM2 patch editor the Release Level effects only the end of the envelope.  Either the statement in the manual is not quite correct, or there is a bug in the patch editor.  Can anyone clue me in here?  Additionally, perhaps it would be best if the patch editor's "sustain" was a horizontal line of some length (indicating sustain), as is common, rather than a single point.

19. It appears that the PreenFM2 dumps a number of NRPN parameters which do not correspond to any documented feature, perhaps as gap-fillers, though I'm not sure why.  Just verifying that the following NRPN parameters do not correspond to anything:

14
15
36
37
38
39
119
123
127
131
135
139
143
147
151
155
159
163
199
190
191
194
195
203
207


20. Algorithms 14 and 9 are essentially the same.  Similarly, 15 and 8 are the same.  Why is this?  I thought maybe it was compatibility with the DX7 algorithms, but they don't seem to line up.