Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - feijai

Pages: [1]
1
PreenFM2 / Edisyn Patch Editor for PreenFM2
« on: August 21, 2017, 05:08:39 AM »
I have made a patch editor for the PreenFM2 for Edisyn, my patch editor tool.  Edisyn runs in Java and works on OS X, several versions of Windows (I am told), and Linux.  Edisyn's PreenFM2 editor is feature-complete.  Edisyn has a lot of facilities for exploratory patch programming -- and in fact over the next few months I'm going to use it as a basis for some new facilities to make FM programming easier.  Anyway, check it out.

2
PreenFM2 / Arpeggiator Latch and All Sounds Off
« on: August 01, 2017, 12:03:19 AM »
This seems like a bug to me, but it's up to interpretation.  If the Arpeggiator Latch is ON, then sending All Sounds Off does not turn off arpeggiation.

Generally an All Sounds Off is used as a panic button: "make the dang synth shut up!".  But the PreenFM2 won't shut up in this context.  I note that the on-board panic button on the synth does shut the sound up.  It seems to me that All Sounds Off should do the same.

3
PreenFM2 / Full-Speed NPRN dump crashing
« on: July 31, 2017, 06:25:50 PM »
It looks like I can't send a full NRPN dump to the PreenFM2 at full MIDI speed.  It crashes about one times in five.

I'm testing this on my patch editor written for Edisyn, and when I do "randomize" (which sends a random valid patch to the PreenFM2), it'll crash hard at about that rate.  If I force Edisyn to only send out NRPN once every 1ms (ugh) then the PreenFM2 doesn't appear to die.  Keep in mind that MIDI is about one byte every 1/3ms.  This means I have to wait for about two seconds :-( :-( to update a patch, whereas at full MIDI speed it'd be a small fraction of a second.

This looks like a buffer overflow.  All told I'm sending (I believe) 227 NRPN messages, so 908 CC messages or 2724 bytes.

4
PreenFM2 / PreenFM2 is sending me NRPN dumps four times in row
« 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.

5
PreenFM2 / 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.

6
PreenFM2 / 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.

7
PreenFM2 / 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?

8
PreenFM2 / 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:

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

Pages: [1]