In depth discussion: "About a PAD pair note number"

The "something about pad pair number" is an advanced discussion but also an extremely important one.

http://www7a.biglobe.ne.jp/~mpc1000/os2/pad_note.htm

I believe JJ should abandon this concept and implement JJ OS1 like functionality in JJ OS2XL as far as midi/pad-mappings are concerned. Here follows an in depth discussion why...

Since JJ OS2XL is on it's way this is a great opportunity to discuss this and maybe convince JJ. Anyone who takes a deeper look at this might come to the same conclusion as me. I'm not saying I'm right and I'm definitely not saying JJ is making a bad OS. However I believe JJ made a mistake with the current concept and I'm really interested in hearing anyone thinking I'm wrong explaining why.

--

Anyone who has had problems when trying to re-map programs to conform with en externally loaded midifile will be affected by this.

Anyone who has experienced programs (with identical but remapped pad layouts) responding differently to a sequence depending on if they are from JJ OS2 or JJ OS1 (Pad 187 and AkaiOS) should be interested.

It also has a huge impact on how MPC works with external midi keyboards.

--

Here are the biggest problems with the current midi-to-pad/pad-to-midi mapping concept:
=======================================================
1. When loading an external midi file (not a SEQ file) there's no way to adjust an MPC-program to correspond to the midi file. Example: midi file plays kick on C3. I want my Kick on pad A01 (or it's there already) - remapping makes no difference (it did on OS1). The only solution is to process the midi file with third party software on a computer, converting C3 to C#1, which is the default for pad A01.

2. When loading (remapped) OS1 programs and sequences (SEQ) on OS2 the results will differ depending on which is loaded first. Results varying depending on in which order files are loaded is very bad functionality and big cause for confusion.

3. When playing a remapped program (created on OS2) from an external keyboard, the mappings will not have any effect on the sounding result, pads will not change from default mapping. At midi out the original keyboard value is shown. At the same time the midi numbers presented in Step edit will indeed be the remapped values. When playing the pads on the MPC the remapped values are also presented both in step edit and midi out. This is very confusing and irregular.

4. The JJ OS2 concept contradicts the fundamental philosophy behind the MPC note mappings as described on page 78 in the Akai MPC 1000 user's manual. Although generally Akai OS is not as good as JJ OS2 this particular concept is really well designed, easy to use and to understand. The JJ OS2 version is confusing. The main reason why is that there is no bidirectional 1:1 correspondence between notes and pads anymore. In OS" a note 37 will always correspond to pad A01 while A01 at the same time can be mapped to another note; say 60 (C3). The result being a sequencefile containing 37 will be presented as 60 in step edit, A01 will sound although 37 (the data in the sequence) is mapped to another pad in the program map.



Here is an example which anyone who is interested could try:
===============================================
(external keyboard and midi monitoring needed)
Create a JJ OS2 DRM program and use in a sequence with track set to DRM mode. Let pad A01 be remapped to note 60 and pad C05 be remapped to 37 to avoid duplicates. Assign samples to the pads to make it easier to investigate.
(i). Hit PadA01 on MPC, pad A01 will sound midi note 60 will be sent on midi out during recording and playback. OK!
(ii). Hit C3(60) on keyboard, pad A01 will NOT sound but still note 60 is sent to midi out during record. Playing the recorded sequence will send 37 instead. Step edit shows 37 as well. NOT OK!
(iii). Hit C#1(37) on keyboard, pad A01 will sound but midi note 37 is sent to mid out. Note that in (i) pad A01 sent midi note 60. In playback and step edit 60 is presented. NOT OK!

With more complicated re-mappings and also when working with external midi files, these anomalies gets much worse. One could argue I shouldn't use DRM track mode for playing external midi but using MIDI track mode doesn't solve all these problems. Especially the mapping (or rather lack of) from external keyboard to pads is identical in both modes. There's still no way to use mappings with external midifiles. 50% of the functionality of mappings is lost in JJ OS2!



Discussion
========
My conclusion is that all these problems originates from a fundamental design mistake in JJ OS2. The general problem is that the pads have been given the mixed function of representing both sound data AND performance data. It's a much better idea to let the Pad represent sound data (like a S1000 keygroup) and let midi note number (ond such) represent performance data. A bidirectional mapping binds events to pads through the note-pad mapping.

The concept of mapping notes from the sequencer to pads in the sampler in JJ OS1 and Akai OS is much better. There the mapping is always 1:1 and bidirectional. If pad A01 is note 60 then playing 60 (on midi in, external midi file or internal sequencer) will trig A01 and note 60 is recorded. Playing pad A01 will produce 60 on midi out and on recorded sequence. This makes sense. If a program with another mapping (lets say where pad C09 is mapped to 60) is loaded then C09 is heard when note 60 is played on a sequence. This also makes sense.

In Akai OS and JJ OS1 a midi note and pad pair works both ways and you know that the pad will trigger the note number and the note number will trigger the pad. There's no magic, it's pure and simple. 60 is A01, A01 is 60 - everywhere.

This also makes it extremely easy to re-map a program to conform with external sequences, like grooves loaded from standard midi files. In JJ OS2 you can't re-map.


Duplicated representation = bad design
==============================
Theoretically speaking; in the JJ OS2 implementation; data representing an event (a note or a pad is hit) is written twice to the sequencer, both as midi number and pad number. Generally it's a very bad concept to represent and write data representing the same entity duplicated. It's usually a big cause for confusion and data corruption. It's also a waste of space.

I believe JJ invented this duplicated concept to solve what he refers to as the "Pad pair note problem". Maybe I don't fully understand this problem but I'm pretty sure he introduces a bigger problem with the duplicated pad-number/note-number concept.


Finally
=====
JJ OS and JJ are great. This discussion is not about whether his project is good or bad. This discussion is about trying to make JJ OS2XL even better by pointing out what I believe is a design error. A design error made with the best of intentions but maybe worth reviewing and correcting.

the dual and bidirectional concept has been in akai & jjos1 inside the PGM files...
on os2 i don't know it.

the format PGM files on os2 is a secret from JJ

a good post. i don't know where i stand fully on it. i work better on os2 than i did ever before and i dont lose any functionality in my workflow, but i have bumped heads with this on rare occasion

me, what i have always thought, is that there should be NO distinction between MIDI and DRUM tracks.

as of now, the new specification may be very entrenched in os2. i would most like the "path of least resistance" as far as programming goes - whichever will cause least problems A, on the grand scale of os2xl, and B, for os2 project transfer.

i never import midi and i use a simple midi controller setup
i turn all of my tracks to MIDI by default and never use DRUM

yo, props for spending so much thought on this issue. it's a difficult one, for sure. you clearly know your shit and have been thinking about this a lot. we need folks like you on board.

the information about de PGM files on akai os & jjos1:
http://mybunnyhug.com/fileformats/pgm/

I agree there should be no distinction between midi and drum tracks, there's no need for that really, as far as functionality goes. But when editing drum tracks I prefer the grid edit of drum tracks, it's very nice so I wouldn't want to lose that. But instead of switching between two track types I could switch between the two editing windows depending on my preference.

Then there's the internal sequencer data from sliders inherited from the Akai OS, I guess separating that from pure midi tracking is a reason to keep the drum track concept.

-

I used to think mappings were an easy thing, both on MPC and DAW:s. It used to mean "this note goes to that pad, that pad goes to this note". It wasn't until JJ OS2 it became difficult.

I had to spend all this time working out how it was set up in JJ OS2 to solve my problems when converting and old song from Logic, reading midi files and remapping drums. The thing was, I experimented on JJ OS1 first and it was a breeze, but then I needed some functionality on JJ OS2 and switched nothing worked anymore and I couldn't figure out why, at first.

Surely I'm not the only one puzzled by this but unfortunately I guess most people having similar problems never understand what's wrong -wasting a lot of time. I guess most won't read my lengthy post either, which I understand. It's very difficult to understand all this.

My hope is that JJ reads it. I believe I have a very good point. Mappings the JJ OS2 way is a mistake since it removes 50% of mapping functionality, namely mapping from-midi-to-pad.

torsig1967 wrote:My hope is that JJ reads it. I believe I have a very good point. Mappings the JJ OS2 way is a mistake since it removes 50% of mapping functionality, namely mapping from-midi-to-pad.

i think if you want JJ to read and understand all of your points it would be a good idea to find a native Japanese speaker to translate it for you and then email it to him directly. i don't think JJ reads these forums and both him and Murai (his web helper) don't have a solid grasp of english. english communication with them works the best when it is short and very simple and clear. if you could make your ideas very simple and direct (like bullet point 1, 2, 3, etc.) then it might work.

Sooty_G wrote:english communication with them works the best when it is short and very simple and clear

Guess you're right. Making this lengthy post helped me grasp the issue. I think I'll try to post a very (very) short version to him.

lol is he a board memeber nice one

I've just been doing a little hacking and the midi note/pad number mapping definately exists in the OS2 file format...so dont worry - jj just needs to add it to the frontend on JJOS for it to work.

I might just go ahead and add this functionalilty to my MPCTool software so you guys can do this until JJ adds it to the OS.

KidQuaalude wrote:...and add this functionalilty to my MPCTool software...

what software is this?...

Okay, updated the program to allow editing of midi note->pad mapping and it appears to be working fine.

You can get it here : viewtopic.php?f=25&t=102160&p=945769#p945769

KidQuaalude wrote:I've just been doing a little hacking and the midi note/pad number mapping definately exists in the OS2 file format

Yes, surely it's there in program edit. The problem is the new way JJ OS2 interprets it. It's different from JJ OS1 by design.

I'm hoping JJ returns to the original design from JJ OS1 when releasing JJ OS2XL.

no, the mapping of midi note# (midi in) is not there in program edit, only mapping of pad -> midi note # (midi out)...the mapping of incoming midi note # to pad exists in the file but is not editable in the JJOSv2 frontend. my program gives you a way to remap incoming midi notes -> pads until JJOSv2/XL allows this.