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.

Messages - feijai

Pages: [1] 2
PreenFM2 / Re: Edisyn Patch Editor for PreenFM2
« on: August 30, 2017, 06:50:14 AM »
Writing a patch editor for a synth in *ANY* toolkit is hard because you'll have to do many of the following: (1) lay out the widgets (2) write the patch dump parser (3) write the patch dump emitter (4) write the code to issue requests for patch dumps etc. (4) write the code to send individual parameter changes (5) write the code to respond to individual parameter changes made on the synth. 

All synths do these things in completely different ways, have lots of bugs in their communication protocols, etc.  And to be complete you'd need to write separate editors for single-mode and multi-mode etc.

That being said, in Edisyn I tried really hard to make patch editors relatively easy to code, while at the same time providing a lot of flexibility so you can handle the particular weirdness of the synth you're dealing with. 

And Edisyn provides a whole lot of built-in features that you get for free: lots of widgets, MIDI handling facilities, CC or NRPN mapping, pass-through from a controller, saving and loading sysex files, and a host of exploratory synth programming options, like variable randomization and mutation, patch merging and recombination, nudging your patch towards other patches, and (soon to be released) a full-featured hill-climber.

BTW, you mentioned the Microwave. Edisyn already happens to have good-working patches for the Microwave II, XT, and XTk.  Not the Microwave I: I don't own one.

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.

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.

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.

PreenFM2 / Re: Revised PreenFM2 MIDI page
« on: July 31, 2017, 04:58:23 PM »
I've found a problem with the Preen's NRPN dumps violating its ranges.

Bank 3, Patch 2 ("Resolead  MB").  When loaded, OM Index 1 is 18.0 and Index 2 is 25.0.  This sends NRPN values of 1800 and 2500 respectively, outside the 0...1600 range specified.  This causes two problems:

1. You can't use the knobs on the machine to go to 18 or 25.  So you can *load* this patch but you cannot *create* it (!?)

2. It's not clear what the upper limit is over NRPN.  What should a patch editor do?  Should I bound it to 0...1600?  Then if I send it back, it's a different sound.


I'll take a look at your #3. Doesn't it work with my editor ?
(I cannot verify right now).

It's the NRPN closed with RPN 127/127 issue mentioned elsewhere.  :-(

Well, NRPN has always been very, very vague in the spec.  But here's the rules regarding receiving machines (see MIDI 1.0 Detailed Specification 4.2, page 17).

"4. The receiver should be able to respond accordingly if the transmitter sends only an LSB or MSB to change the parameter number.  However, since the transmitter can't know when reception was enabled on the receiver which will be waiting for both the LSB and MSB (at least initially), it is recommended that the LSB and MSB be sent each time a new parameter number is selected."


"5. Once a new Parameter Number is chosen, that parameter retains its old value until a new Data Entry, Data Increment, or Data Decrement is received"  [I think this is interpreted as also permitting NRPN running status -- that is, a stream of data entry values -- though it's vague]

I think that this means that receivers are asked to be able to handle single LSBs, single MSBs, and LSB+MSB pairs (it doesn't specify the order).

Given that the PreenFM2's *primary mechanism* for control is NRPN, I'd STRONGLY recommend revisiting this to get it right.  The big issue is what happens if only a CC6 (or stream of CC6) is sent -- this is a common case and makes perfect sense.  For example, if I have a BeatStep and I want to control the Preen's Operator Modulation Indices, the BeatStep can *only* send either CC6 *or* CC38.  CC6 lets me change the indexes by a significant amount, CC38 does not.  So that means I can't really use a BeatStep with the PreenFM2 over NRPN.

Also, the inability to close properly with an RPN 127/127 is going to cause problems with a number of utility devices which were written to assume this.

I'll try to suggest a protocol that might work.  But it will almost certainly involve freeing up CC100 and CC101.

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

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

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.

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

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.

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?

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

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.

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.

Pages: [1] 2