MIDI - a summary of important pending things

[Soli Deo Gloria]

Well, as far as rewire goes, we´re not there yet; it seems that some glitchy issues still persist...

[ELP]

The native Reaper-V5 Clock+SPP(REAPER as Master) is now improved and optimized!

A. lower jitter (System Realtime 0xF8)-
(comparison:the raw 0xF8 jitter is lower than within other TOP DAW products)

B. SPP send (timeline position)

B.1. Before V5- one SPP after pushing Start
(unnecessary and can result in glitches/muting etc.pp. if the Slave position handling is maybe to slow)
and one after pushing Pause/Stop.

REAPER V-5 now send only one SPP after pushing Pause/Stop

B.2.During Pause/Stop:

-after moving the Cursor REAPER V5 send the Timeline-Position(SPP).
So if you move the Edit Cursor, Slaves can move to the same position as REAPER(during Pause/STOP/Editing)
- works with ext. MIDI/Rewire

B.3. Loop-playback and SPP
No SPP was send if loopstart = start of the project
(fixed with 4.78 and V5)


I can say that the native REAPER V5 MIDI Clock+SPP is now really improved over REAPER<5
And it is as it is- the jitter is now lower than in some other TOP DAWs

---
Things that Users should avoid -should be fixed:
If you use Pre-Roll and or Count-In together with the MIDI-Clock+SPP(Master)
Avoid to start at:
Measure/beat Position -(Pre-Roll lenght + Count-In lenght) < 1

Otherwise the Slave move to top project positions during count in and dont follow REAPERs position if the Pre-Roll/Count In ends
---

#######

Options for the native Software MIDI Clock+SPP
that are -at the moment- missing:

A:For Slaves that are Beat/Pattern oriented and if you which that the Slave intern always START at position t=0, no matter which position at REAPERs timeline

A.1. Always send START/no CONT (YES/NO)

B: For Slaves that cant handle position pointer(SPP) during loop-playback, resulting in unwanted things.

B.1. Clock follow timeline (YES/NO) -(no SPP send during loop)
(But that of course result in that Slaves dont follow REAPERs timeline during loop-playback but avoid unwanted things)

C: Always send Clock (YES/NO) -(send 0xF8 during Pause/Stop)
-After pushing start, Slaves dont have to wait for at least two 0xF8 to calculate the tempo at the timeline position.
######

[Mink99]

B3 is only partially fixed, as when the loop is not at t=0 it still won't work.
The latency issues are still immanent, so we have a high latency low jitter implementation.

Did Some Jitter Test too:

setup : reaper 4.78 and 5 rc14b --> Loopmidi --> MidiTest 4.6

results of 4.78 :

MESSAGES Snd Rcv Snd+Rcv

Message TotalTime: 638.31 ms 589.33 ms 1227.64 ms
Message MaximumTime: 0.12 ms 16.14 ms 16.20 ms
Message MinimumTime: 0.02 ms 0.00 ms 0.02 ms
Message AverageTime: 0.02 ms 0.02 ms 0.04 ms
SysexTime: 0.00 ms 0.00 ms 0.00 ms
SysexAverage: 0.00 ms 0.00 ms 0.00 ms

< 1 ms: 31250 31249 31249
1 - 2 ms: 0 0 0
2 - 3 ms: 0 0 0
3 - 4 ms: 0 0 0
4 - 5 ms: 0 0 0
5 - 10 ms: 0 0 0
10 - 20 ms: 0 1 1
20 - 50 ms: 0 0 0
50 - 100 ms: 0 0 0
> 100 ms: 0 0 0

Message count: 31250 Sysex count: 0
Sysex size: 0 Sysex passed: 0

Message latency: 0.04 ms Total time: 5.190 sec
Message jitter: 0.11 ms
Message max deviation: 16.16 ms


Results of 5.rc14 b

================ Results Per Message =====================================

MESSAGES Snd Rcv Snd+Rcv

Message TotalTime: 648.94 ms 961.85 ms 1610.80 ms
Message MaximumTime: 0.15 ms 13.33 ms 13.37 ms
Message MinimumTime: 0.02 ms 0.00 ms 0.02 ms
Message AverageTime: 0.02 ms 0.03 ms 0.05 ms
SysexTime: 0.00 ms 0.00 ms 0.00 ms
SysexAverage: 0.00 ms 0.00 ms 0.00 ms

< 1 ms: 31250 31224 31206
1 - 2 ms: 0 22 40
2 - 3 ms: 0 1 1
3 - 4 ms: 0 0 0
4 - 5 ms: 0 0 0
5 - 10 ms: 0 1 1
10 - 20 ms: 0 2 2
20 - 50 ms: 0 0 0
50 - 100 ms: 0 0 0
> 100 ms: 0 0 0

Message count: 31250 Sysex count: 0
Sysex size: 0 Sysex passed: 0

Message latency: 0.05 ms Total time: 11.141 sec
Message jitter: 0.16 ms
Message max deviation: 13.32 ms

-------------------------------------------------------------------------

these results eliminate the internal jitter of the USB Interface. Some old results from XP show the jitter of external devices :

Interfaces

1.) LoopMidi (http://www.tobias-erichsen.de/software/loopmidi.html) um die interne Latenz des Midi Subsystems zu testen
2.) Esi M8UXL
3.) Motu 128 express
4.) Roland UM 1G

Testsystem : Win7 / 64 16 Gig / AMD 6 Core
miditest (http://miditest.earthvegaconnection.com/) 64 bit
Midi Clock / SPP / Note On - Off
no Sysex
loopback from interface input to output

1.) Internal

Message latency: 0.02 ms
Message jitter: 0.02 ms

2.) Esi M8U XL

Message latency: 1.14 ms
Message jitter: 0.12 ms

3.) Motu 128 express

Message latency: 4.72 ms
Message jitter: 0.35 ms

4.) UM-1G

Message latency: 1.76 ms
Message jitter: 0.32 ms

-----------------------------------------------
as Comparison :

results for Ableton V8.64

================ Results Per Message =====================================

MESSAGES Snd Rcv Snd+Rcv

Message TotalTime: 649.36 ms 1097.35 ms 1746.71 ms
Message MaximumTime: 0.16 ms 18.57 ms 18.66 ms
Message MinimumTime: 0.02 ms 0.00 ms 0.02 ms
Message AverageTime: 0.02 ms 0.04 ms 0.06 ms
SysexTime: 0.00 ms 0.00 ms 0.00 ms
SysexAverage: 0.00 ms 0.00 ms 0.00 ms

< 1 ms: 31250 31249 31249
1 - 2 ms: 0 0 0
2 - 3 ms: 0 0 0
3 - 4 ms: 0 0 0
4 - 5 ms: 0 0 0
5 - 10 ms: 0 0 0
10 - 20 ms: 0 1 1
20 - 50 ms: 0 0 0
50 - 100 ms: 0 0 0
> 100 ms: 0 0 0

Message count: 31250 Sysex count: 0
Sysex size: 0 Sysex passed: 0

Message latency: 0.06 ms Total time: 10.957 sec
Message jitter: 0.16 ms
Message max deviation: 18.61 ms



================================================== ============

1.) I cannot recognize any significant improvement between R4 and R5
2.) the jitter is internally below 0,2 msec so this can be completely ignored, as the internal jitter of the USB subsystem, the devices and instruments is larger.
3.) it looks as if a problem was solved that nobody really had....

[ELP]

Hello mink99.

The ground problem with loop-playback together with MIDI-Clock+SPP
is that the System Realtime message Clock and the System Common Message-SPP of MIDI is never really been designed for Looping/loop playback.
Some works within that special playback mode, some not.

But REAPER now follow absolute the MIDI Clock+SPP rule for sending these messages.

And yes, the workaround options for Slaves see above,
should be implanted.
But I'm pretty sure that they will too. Except perhaps C.

Let´s wait and distribute sugar for the Cockos Team.

PS With MIDI Test you cant measure the Output of REAPER. You measure the event output latency/jitter within Miditest themselves
The App send messages to the MIDI output and measure the self sending messages at input.(loopback)
It´s quite the same as measure the latency of Audio via loopback.
If you really want measure REAPERs output you need some hardware (like i did) or app that can graph/writing REAPERs 0xF8 output in microseconds needed between each 0xF8. For a long distance of course.
And if you know how much jitter your involved Hardware-Devices generally produce you have the raw jitter between each 0xF8.

But you can really see the difference already with eyes.
Simply start MidiOX or whatever app that can capture the Clock or work as slave, connect with loopmidi, go within MIDIOX to the Send Clock Dialog but not send the clock and simply have a look at the MIDI-OX calculate BPM tempo RCV from REAPER.

It is much better and stable at the calculate Tempo than before and also better than other DAWS did.

[Mink99]

I completely agree

Midi clock perfectly supports looping. SPP makes no sense because SPP implies the existence of a song, which does not exist in a looping scenario. This is why Ableton has a switchable clock : Loop & Pattern.

That no improvements regarding jitter are there, i do not mind, as there never was any problem.

Let´s wait and distribute sugar for the Cockos Team.

This was the error on our side: when we celebrated the 5th Anniversary of the SPP/Loop bug we did not provide candy.....

[Mink99]

regarding MidiTest :

afaik if the option "Use Timestamp" ist checked, the application generated timestamp is used.

[ELP]

Ah yes I forget completly the timestamp option

Short test with that over Loopmidi from Tobias Erichsen via kernel streaming/direct music (Ks & DM use qpc timer for inp.)

Abelton Live 9 Clock send at 120BPM/ppq int resolution :
Byte count: 5005 ;Comment 5005 * Clock Event Byte xF8
Byte latency: 19.13 ms
Byte jitter: 1.27 ms
Byte max deviation: 3.59 ms
---------------
Cubase 8 send Clock at 120BPM/960ppq
Byte count: 5005
Byte latency: 19.29 ms
Byte jitter: 1.04 ms
Byte max deviation: 5.16 ms
---------------
REAPER 5 Clock at 120 BPM/960ppm
Byte count: 5005
Byte latency: 19.34 ms
Byte jitter: 0.96 ms
Byte max deviation: 3.00 ms
---------------

And the low jitter/deviation MIDI Clock winner of these three TOP DAWs is?

Latency is not really important for a good stable BPM Slave Clock.
Low jitter and low deviation is it.
And Steini has a real bad deviation. Maybe they need/want to sell more of their expensive Hardware Sync Gear.

dont forget the sugar, ^^
I was not exaggerating if I wrote:
REAPER V5 has maybe the lowest software Clock jitter i ever saw from a DAW!!

You do really one excellent job for that Justin.

[Mink99]

Latency is not a problem if it can be properly compensated. That's true.
The "if" is reaper's problem.


And I do not see any jitter problem in the daws mentioned. They are well below 2 msec.

Some hardware boxes, Roland's with a J starting in the name, the famous and underrated venom, and may others are much worse.

[Soli Deo Gloria]

I must say that my experience with rewire sync has improved remarkably after v5 rc14b.

Guys, if you want to help me to discern which entries of the list can be removed after these fixes I´ll be updating it during these days.

Thanks so much for all the feedback!

[Mink99]

Isn't rewire another topic ?

[ELP]

Fine Soli.
No mink.
That´s why the SPP/Timeline/Cue Point send after moving the Cursor was so important and also all the other changes to that.

These are the same pair of global MIDI-Rewire and Sync shoes.
You understand..^^

This -also for rewire and not only if Clock+SPP is active- works only from 5.rc14b
and of course with the REAPER V5 Main release and higher.
---

Ok Soli Deo Gloria no problems, I will look

[Lazarus]

The multiple midi output and per-output comp stuff does not belong in MIDI basics. Neither does the sync stuff. Basics are things that pretty much everything else has or they are not basics.

[Mink99]

Originally Posted by Lazarus

The multiple midi output and per-output comp stuff does not belong in MIDI basics. Neither does the sync stuff. Basics are things that pretty much everything else has or they are not basics.

Please do not feed the troll

[Lazarus]

Meow.

[Mink99]

Originally Posted by ELP

Fine Soli.
No mink.
That´s why the SPP/Timeline/Cue Point send after moving the Cursor was so important and also all the other changes to that.

These are the same pair of global MIDI-Rewire and Sync shoes.

Sorry, but I do not get the point. Rewire will sync two daws in a way that a slave
... Uses the audio subsystem on the master
... Uses the positioning and tempo information of the master
.... Will receive and transmit midi from / to the master.

But the underlying communication protocol is not midi based, the positioning / tempo info are not transmitted as midi clock and spp. (https://www.propellerheads.se/develo...rewiretechinfo)

Although I am very pleased about the first step to clean up the spp jungle, I do not get the connection of this with rewire ? (No rhetoric tricking, serious question)

[Soli Deo Gloria]

Well, i can tell you that in my case - with Sibelius as rewire slave sending datai via LoopMidi since it cannot do it natively via rewire - the fixes had, only after rc14b - a noticeable impact... (I didn't explain the issue properly, sorry).

I'll have to go on later, but thanks again guys! Your contributions are really helpful!

[Mink99]

So you are rewiring Sibelius by rewire for sync, locating (audio ?) and run the midi communication through loopmidi ?

[Icchan]

Originally Posted by Lazarus

The multiple midi output and per-output comp stuff does not belong in MIDI basics. Neither does the sync stuff. Basics are things that pretty much everything else has or they are not basics.

If you read the MIDI specification (which is one of the most comprehensive and clear specs out there) you know what any host or any device should support and how.

The thing is, that the specification is just that, a spec. You don't need a licensing procedure to be able to make a device that supports that spec and thus the quality or amount of support is up to the maker of that product.

But one thing that is mentioned a few times in the MIDI spec is, that the timings have to be tight for accurate synchronization of the devices. But unfortunately this is much easier to achieve in the hardware realm or with RISC processors running real-time code than in modern computers.

It's much more difficult to achieve this when you have different buffers between each transaction of data that goes trough ten different layers that each have their own way to deal with the data etc. Coupled with operating systems that aren't real time capable (windows 10, OSX)

But even after 30+ years the MIDI is still running strong, why? Because the spec is solid as anything. Easy to implement and just works. It's always the implementations that have trouble coping with the changing structure of computers and other devices.

Even windows 10 is implementing new API's for midi which is incredible to think of:

http://www.sonicstate.com/news/2015/...re-a-big-deal/

[Lazarus]

Originally Posted by Icchan

If you read the MIDI specification (which is one of the most comprehensive and clear specs out there) you know what any host or any device should support and how.

The thing is, that the specification is just that, a spec. You don't need a licensing procedure to be able to make a device that supports that spec and thus the quality or amount of support is up to the maker of that product.

But one thing that is mentioned a few times in the MIDI spec is, that the timings have to be tight for accurate synchronization of the devices. But unfortunately this is much easier to achieve in the hardware realm or with RISC processors running real-time code than in modern computers.

It's much more difficult to achieve this when you have different buffers between each transaction of data that goes trough ten different layers that each have their own way to deal with the data etc. Coupled with operating systems that aren't real time capable (windows 10, OSX)

But even after 30+ years the MIDI is still running strong, why? Because the spec is solid as anything. Easy to implement and just works. It's always the implementations that have trouble coping with the changing structure of computers and other devices.

Even windows 10 is implementing new API's for midi which is incredible to think of:

http://www.sonicstate.com/news/2015/...re-a-big-deal/

RISC vs CISC (x86 is sort of RISC under the hood these days btw) has little to do with it because you can run real time systems on either. Windows is also real-time capable, both embedded and full flavoured versions, with RTXs in the latter case. But I know what you are getting at. It's great that MIDI is continuing to receive the attention it deserves too.

The core reserving thing Microsoft are working on looks very interesting btw, we could be seeing the beginnings of RTX Lite coming to the average desktop before long!

Anyway, MIDI spec notwithstanding there are clear duplicates and related items on the OP's list. Even if you guys still want to call it "basic" which has negative connotations in English and is is a comparative rather than a technical term that's nothing to do with me. But the section contains issues outwith the remit of the MIDI spec in any case.

But it's just a list, even if it has a bunch of duplicates. Personally I think the priority should be on issues that don't have solutions/workarounds. But that's just me.

[Soli Deo Gloria]

Originally Posted by Lazarus

The multiple midi output and per-output comp stuff does not belong in MIDI basics. Neither does the sync stuff. Basics are things that pretty much everything else has or they are not basics.

Do you really think MIDI sync and the possibility to handle (natively) multiple inputs/outputs per track are not basic features? I don´t think many around here would support that argument, but anyway, give us a couple of strong arguments... I don´t think that something has to be present in every MIDI app/hard to be considered a core functionality...

Originally Posted by Mink99

So you are rewiring Sibelius by rewire for sync, locating (audio ?) and run the midi communication through loopmidi ?

No audio is involved from Sibelius, indeed. It only acts as the scoring tool that sends MIDI via a loopback device (mostly LoopMIDI in my case, nowadays, and also LoopBe30). Reaper is the VSTi/VST host, MIDI programming platform (with a Bidule plugin on each track to do any MIDI manipulation I could think of) and playback mixer in which I can prepare what´s going to be the audio mix right from the scoring phase. Rewire is the sync protocol I use because there is no other available in Sibelius for now. Before rc14b there were playback glitches here and there, depending on the position where you put the cursor. Now, after days of working extensively with it, it certainly shows a remarkably improved behaviour.

[Lazarus]

Originally Posted by Soli Deo Gloria

Do you really think MIDI sync and the possibility to handle (natively) multiple inputs/outputs per track are not basic features? I don´t think many around here would support that argument, but anyway, give us a couple of strong arguments... I don´t think that something has to be present in every MIDI app/hard to be considered a core functionality...

Not every, but certainly most or at the very least a sizeable minority of top DAWs. So if you can name all of the sequencers that have multiple MIDI input and output ports per track without routing that would provide an argument for inclusion in the list. It's not logical to ask me to prove a negative here.

There's native routing in Reaper with a native MIDI buss-system that multiplies routing possibilities by x16 anyway, so I suppose a more pertinent question would be what basic functionality is missing here if this is indeed a "basic" feature?

Anyway, 5.01pre3 has introduced an option to not send SPP or Continue messages with MIDI Clock so Mink99 can remove a plugin from his projects now and complete his transformation into a Great Red Dragon and you can remove all of the entries from the different sections of your first post that were about that.

[ELP]

"Mink: Uses the positioning and tempo information of the master"
Yes of course but:
It´s quite as easy. Before 14b, REAPER never send any new timeline position after moving the Cursor during Pause/Stop.
Only after pushing Start.
And that´s why it related to the same pair of shows.
With or without additional extra virtual Midi device.

But that's not important.
So I mean it needs no extra discussion about that.

The only thing that counts is: now it rocks!

----
There are also other things, that REAPER dont do during Pause/Stop and after moving the E(Start)Cursor, like chase.
That´s also very important and refers not only to MIDI>Hardware^^
The same pair of MIDI shows
----

5.01pre3
+ MIDI: allow sending MIDI clock without SPP/continue messages, for certain devices

refers to:

Workaround(s) for single Beat/Pattern oriented Slave devices that cant handle SPP+CONT correctly
or if the User wishes that the Slave always Start intern at t=0
is now integrated with REAPER.

Work as follow:

A: (SPP)
-No SPP send after pushing Pause/Stop
-No SPP send after moving the Cursor
-No SPP send during loop

B: (CONT&Loop)
-always send Start(T=0) never Continue(T>0)

The MIDI Message behavior for active Timeline Loop at Master is now as follow:
Master Loop-Startpoint
always send MIDI-START(Slave resets/move intern to t=0 and starts playing)
>
Master Loop-Endpoint
send MIDI STOP(Slave Stop)
-----
An somewhat unorthodox but very good workaround solution
for the master & slave loops together with the master loop- at the same time.

Also possible no Stop at loopend but then there are Slaves outside that dont reset/break there voices/notes at loop-end.
Some Slaves reset/break older notes/voices together with a START,
some only with a STOP and some do it with both messages
So the above is the best solution.

The endless REAPER topic
MIDI Master Clock
+ Timeline positions send
+ Workaround for different Slaves faults
can now be really finalized!

Great work!
Thank You very much REAPER Team


-or maybe "strict conventionally" without Start+Stop messages -within loop, but then of course
the slave do not follow any master loop timeline and the Slave has to loop by its own.
Both is possible.
hmmm may be for single pattern oriented slaves
it´s better without Start+Stop and dont follow the master loop timeline..

--------
EDIT
# Reaper501pre4 changed "WaR" Message within loop to "-or" see above.
EDIT
--------


additional Info for User:
With always send START t=0 & no SPP that means of course
that if you start REAPER inbetween the measure-Bar(Loop or not)
you get always the Slave notes/voices from the Start of his measure-Bar at t=0.
So it is maybe not a really good idea to loop or Start
REAPER inbetween the start of the measure.
-Unless you want it that way and know what do you doing

So it is not a bug it is simply the behavior for such "WaR" messages.
There is no other way with System Realtime/Common
and without SPP+CONT,
exept the involved Slave manufacturer fix/removed his OS problem.

[Mink99]

I just stated in the pre3 thread that the spp / loop bug is fixed.

[Soli Deo Gloria]

So, no sync issues anymore, isn´t it?

[Tod]

Hi Soli,

I ran into a problem today with CCs that I can't explain so I'll just post a little gif I made of it. This is with Reaper 5.01pre2.



As you can see, the left CC is not selected, but it's somehow locked into what ever I do with the mouse. When I left-clicked and dragged, it would drag the CC up and down. If I just left clicked, the CC would move to the mouse position. However, when I just left clicked, it looks like the CC turns on and off like it's getting selected then unselected.

I wanted to add some more CCs right there but I couldn't, and I ended up having to save the project and reopen it. Then everything was fine. I took the little vid before I closed it.

I've tried desperately to reproduce it but can't do it. I thought I'd post it in case anyone else runs across it.

[gofer]

Hopi, that looks much like what the behavior called "Edit CC" does (intentionally). Do you have that assigned for a modifier in the context [CC lane, left drag]?

I have been irritated in the past by very weird behavior when editing and it took me ages to realize that one of my modifier keys would tend to physically get stuck...

[Mink99]

Originally Posted by Soli Deo Gloria

So, no sync issues anymore, isn´t it?

No outbound spp issues anymore. And this *is* good news.

[ELP]

Gofer has right, Tod
Your Default mouse modifier for left drag can only be
"Edit CC events" but it should be
"Edit selected CC events if any otherwise draw/edit" or simular,
if you do not want the/your explained behavior.

The first one named only "Edit CC events" needs no selection and it locks to the nearest #CC event > Mouse Cursor

[Mink99]

Testing external sync, reaper as slave....

Setup : mpc provides clock (mc or mtc) to reaper. Recording back audio from mpc. Reaper clock is pre-set to mpc clock.

First results look promising.

[Tod]

Originally Posted by gofer

Hopi, that looks much like what the behavior called "Edit CC" does (intentionally). Do you have that assigned for a modifier in the context [CC lane, left drag]?

I have been irritated in the past by very weird behavior when editing and it took me ages to realize that one of my modifier keys would tend to physically get stuck...

Originally Posted by ELP

Gofer has right, Tod
Your Default mouse modifier for left drag can only be
"Edit CC events" but it should be
"Edit selected CC events if any otherwise draw/edit" or simular,
if you do not want the/your explained behavior.

The first one named only "Edit CC events" needs no selection and it locks to the nearest #CC event > Mouse Cursor

Thanks guys, actually my left drag is "Edit selected CC events if any, otherwise draw/edit".

That's why I mentioned that the CC that is being adjusted is not selected.

The strange thing is I'd been working in that CC lane for a couple of hours with no problems. As you allude to gofer, it did act as if something was stuck, but it would have had to be the left mouse button and clearly that's working okay. Also I don't see anything in the mouse modifiers that would cause this behavior, like the Shift, Ctrl, or Alt buttons.

I did see some other strange things happen too yesterday. On just a couple of occasions when I went to draw CCs, the left CC suddenly jumped off it's level even though it wasn't selected. That could be related to the problem I show above too.

[Mink99]

Testing external sync finished:

Test Drive:

MPC as Master, providing midi Clock
Vodca Beats receiving midi Clock from MPC
Podolski VSTi internally sequenced by Reaper
Kawai K4 sequenced through MSQ 100, receiving midi Clock from MPC
EMU e5000 ultra sequenced by Reaper

Midi sent through Motu Midi express XT / 360 systems Midi Patcher
Audio recorded through RME Hammerfall / Behringer ADA8200
reaper set to same tempo as MPC
------------------------------------------------

Result:
the first two bars are completely messed up on those tracks where reaper has the control
after that it runs in sync, even correctly compensated.
hear attachment....


this is even better than reaper being the sync master, as it drops some clock events on the first bar.
------------------------------------------------

in comparison to the 4.x behavior this is acceptable. I can work with that, for me the LAtComp Issues can now be ignored, as with external sync this does not inflict the workflow.

maybe some colleagues with different hardware should retest.

[Soli Deo Gloria]

Thanks for the feedback as usual, Mink!!

I have updated the list. If anyone has any suggestion, tell me!

[torreznor]

Reordering pitch names using drag and drop, Cubase-like? I think I said it before...

[Soli Deo Gloria]

Originally Posted by torreznor

Reordering pitch names using drag and drop, Cubase-like? I think I said it before...

Sorry for the delay, I´ve only had time for bug reports lately...

Not a bad idea, sure... But, since we can reorder them easily anyway - editing the names in a .txt file and loading them with a shortcut -it´s not probably something we could qualify as a priority; am I wrong?


Regarding some of the issues in the first list, some nice improvements are appearing in this 5.1 pre cycle! I´ve just updated the list after some tests!

[TechDAWg]

Add this to the MIDI requests. When quantizing midi notes while CC follows Note is activated, CCs and /b]Pitch Bend[/b] associated with each note don't move with the note. That's very annoying with continuous CCs like expression, breath control and Pitch Bend. http://forum.cockos.com/showthread.php?t=167997