Piano roll still sucks?

eclectic play back

A long time ago I got so frustrated trying to use n-Track’s midi piano roll that I didn’t look at it for a while.
Now that we’re several versions away from that time, I thought I’d give it a go again.
But apparently, it still sucks. :(
Can’t even get it to play back a simple (4 bar; 1 note at a time) melody without missing a few notes.
Is there anyone who can guide me to flawless operation of this feature?
Or should I just forget about it and use something else for midi sequencing?

You have buffering issues or something along those lines. It ain’t N-track. Believe me, I have sequenced huge tracks with N and never get what you are describing. Proof of what can be done in N’s sequencer.

So tell us what you are using as a synth. That is the first step.

<!–QuoteBegin>

Quote
It ain’t N-track. Believe me

That seems to be the Pavlovian standard reaction to any problem on this forum. Doesn’t really help IMHO.
Facts are that, in a totally unpredictable fashion, note-ons and note-offs are being left out when playing back a simple, manualy entered, piano roll sequence.
I’ve both been playing it directly to rgc-audio’s sfz-synth and through midi yoke to a midi monitor.
How would this be a buffering issue?

Eyup!

<!–QuoteBegin>

Quote
That seems to be the Pavlovian standard reaction to any problem on this forum.


Not fair Hansje.
People on this forum are very helpful and if you care to read previous posts, you will find most problems are indeed not NTrack’s “fault”, but more usually due to a lack of experience by the user, or problems with soundcard drivers / plugins etc.
Bubbagump gave you a link to a perfectly good example of what can be done using midi. Many other NTrack users, myself included, also use midi and don’t suffer from the problems you describe.
If you truly believe NTrack to be the cause, then post a detailed bug report to Flavio.
Otherwise let’s work through your problem step by step and get it solved.
I’m not a midi expert but the only other instance I know of similar to the one you describe happened with the KX driver, usually with very short notes. I don’t know what soundcard driver you have so it may not be relevant in your case.

Steve

<!–QuoteBegin>

Quote
That seems to be the Pavlovian standard reaction to any problem on this forum.

No, that’s not the case. There are many problems that are n-Tracks fault, and many of us try to help is we can. Bubba asks a very pointed question, and we will try to help.

This particular problem happens with sfz for sure. I can’t use sfz because of it. I couldn’t use it in 3.3 and can’t use it in 4.1. I can however use other vstis and do, without dropped notes. I usually use extremal MIDI and I’ve never seen it happen there, except once (resetting the synth module fixed it). I don’t remember seeing it happen with any other vsti, but all I have are free versions.

Some folks use sfz all day long without any problems. (I don’t know what Bubba uses.) If it was strictly n-Tracks then many more folks would have problems. Possibly, there is a workaround Flavio can add in the future if he can repro the problem with sfz or any other synth that does it. It may be an n-Tracks problem.

Which time clock is being used for MIDI? Which ever it is try switching it to the other one as an experiment.

What are your machine specifics? sfz was much worse on my previous machine (750 mhz) that it is on the new one (3.2 ghz).

[EDIT - addition]
You don’t happen to have any end of notes butting up against note ons do you, or over lapping notes? Some synths don’t like note off and note on of the same value happening at the same time. This is a very common problem when playing legato, especially manually entered quantized notes.

Perfectly quantized notes need to be 1 tick less in then than they usually are. I’ve seen this happen regularly in MANY sequencers, including n-Track. I consider it to be a bug in those apps. Quantize a note to be eactly one quarter note note in length and the note off will have the same time stamp as the next note on. (I just manuully entered quatized quarter note in V4 and it does indeed do this - I think it’s a bug…stil plays fine using my external synth, show that the order of events is working properly for extarnal on my machine.)

You’ll see something like this for two notes in a row of the same value:
Start: 38:02:000
End: 38:03:000
Start: 38:03:000
End: 38:04:000

The problem is here:
End: 38:03:000
Start: 38:03:000

In reality they events should be played in order (is as the case on my machine), but that doesn’t happen all the time. There is no guarantee that events with the exact same time stamp will be played in the order you think they should.

What might actually get played is this:
Start: 38:02:000
Start: 38:03:000
End: 38:03:000
End: 38:04:000

What that sounds like is synth specific. Some synths will cut off all notes of that value with a single note off. Others need to match note on and note off – 8 on needs 8 off to kill all sound. Some synths get confused and you’ll get stuck notes (some old ensoniq synth modules were very bad about this).

Sequencers are really dumb and just spit out notes in a buffer.

OK, I’m sorry if my reaction was a bit sharp there.
I don’t question the intentions of people on the forum. I wouldn’t post my problem if I weren’t expecting help from you.
I guess I was just anticipating the dreaded “it ain’t n-Track” too much to stay polite. Sorry again.

The solution to my problem (if any) must be somewhere inside n-Track though.
I haven’t ever experienced any problems running sfz in any other host or standalone and the notes are missing/hanging too when I simply send them out through midiyoke and monitor the output.
The sequence I’m playing is as simple as it gets: just quarter and 8th notes, nothing overlapping.
I cannot even solidly reproduce the problem. Sometimes it happens sometimes not. This makes it very difficult to nail down where it comes from.

I’m on a p4 2.6GHz 512Mb machine running xp-pro. I’m neither new to n-Track (since 2.x) nor to midi or digital audio in general. Sound i/o = m-audio audiophile usb (ASIO driver) or onboard ac97 (wrapped in ASIO4ALL)

I just saw that midi is on system timer. I want that on wave anyway, so I’ll try that. But still that shouldn’t make any difference when playing just one midi track!

Still don’t see how the buffering settings would affect this (they’re fixed ASIO anyway)?

Thanks for any pointers towards a solution.
H.

EDIT: only saw your edit now. so i’m gonna read that.

<!–QuoteBegin>

Quote
Perfectly quantized notes need to be 1 tick less in then than they usually are. I’ve seen this happen regularly in MANY sequencers, including n-Track. I consider it to be a bug in those apps. Quantize a note to be eactly one quarter note note in length and the note off will have the same time stamp as the next note on. (I just manuully entered quatized quarter note in V4 and it does indeed do this - I think it’s a bug…stil plays fine using my external synth, show that the order of events is working properly for extarnal on my machine.)

You are making an important observation here. I hope the developer takes note!
It’s not the source of my problem though: the sequence doesn’t have any adjacent notes with the same value. :(

I have been using various versions of N with Sfz, and it did work well, with the following observations though : one reason or another, I always had to use midi channel 1 - but I was happy with that and never digged deeper.

The only “quality” sort of issue was when using the free nsKit drumset (and only with this) I randomly get very small “spikes”.

But it never missed a note.

Do you see the chance to build a very barebone system with only N and Sfz with no other midi-whatevers in the middle ?

Quote (Ludo@Home @ Sep. 26 2005,12:57)
reason or another, I always had to use midi channel 1 - but I

I’ve just actually tested that again, and I don’t even see problems with this now …

FYI: I’ve got a lot of crap running under the hood and always have. It’s very possible some of that crap is affecting sfz on my machine. I don’t nuke all that stuff when I record because it’s never generally caused any problems. It would on the old machine when recording drums and playing back any more than 5 or 7 tracks, but that machine was right much slower than this one and I was recording 8 tracks. I have had sync issues when recording recently, but they seem related to effects in use in the playback tracks, posibly related to plug-in compensation. This is something that needs looking into, but is unrelated to sfz not working well for me. Yes, the channel 1 problem sound familiar.

Have you turned up the polyphony in SFZ? It defaults to a very low value and also you may have to tweak how it uses memory. The polyphony setting especially will cause a lot of drop outs if set too low adn try sf32 or sf16 for the memory settings. sf16 takes the least RAM of the two. ALso, crank up your ASIO buffer. If ASIO is not spitting out what SFZ or whatever is feeding it fast enough, you will see notes dropped. Just for giggles, set it to something insanley high like 250ms and see what you get.

Bubba: sfz defaults to 32 (true) voices of polyphony. That should do. Even if not, it will steal old notes rather than skipping new ones.
I have no ram shortage either. Your assumption that the size of the ASIO-buffer might cause dropped notes in the midi stream is incorrect. These things are not connected. If they are, that would be a major bug!
If buffering was too low, I’d have audio drop-outs, not complete midi events disappearing.

Ludo: When I first noticed notes being skipped, I was only running n-Track with just 1 midi track and 1 (sfz) instrument channel. I doesn’t get any barer than that.

Re: the “only channel 1” issue: This is a setting in the sfz-ui. You can have a different .sf2 file loaded for every midi channel. So if only ch1 works, check what is selected for the other channels.

Phoo: I checked the timestamps and you are absolutely right. n-Track times the note-off event of one (quantized) note and the note-on of the next one on the same tick. That should definately be one tick apart.

Eh, I would still try cranking up the polyphony for giggles. I have had some more complex SFs crap out the polyphony even in simple tracks due to how the cross fades and whatever other inefficient junk the SF programmer may have thrown in there.

As for ASIO, correct, it woul dbe auio drops outs. Just trying to get rid of the obvious before we move on as many folks aren’t as hip as you are to troubleshooting.

\Maybe I missed this, but what version of N are you using? There was a bug in an old version doing what you described. Perhaps we are Pavlovian afterall? :;):

Glad to say I finally smoked the bug out for sure.
If I shorten every note by one tick at the beginning and one tick at the end, no more notes are being skipped.
This is not a realistic workaround of course.
So Phoo’s been right about this all along.
Sorry to say this definately looks like a native n-Track problem.

(I have to admit that I still have to update from b1962 to b1969, but I don’t really expect that to solve the problem)

This bug should have been fixed ages ago… Not in a recent build. I cower in shame to being a fan boy…

BTW, I never quantize much of anything, so that is why I have never run into this. I would definately put in an official bug report with Flavio.

Definitely mention again. I think I mentioned it in email to him long ago, but I do such little MIDI work that I wouldn’t hit it normally. I usually do stuff that wouldn’t have the the ends quantized for example, and I’ve always intentionally shorted notes to avoids the situation since Amiga days. I do it without thinking these days.

That said, many synths don’t have any problems with overlapping or butt-ended notes. It could be seen as a synth problem. I’m inclined it say that even if it is 100% a synth problem that an app should avoid it by making the note one tick less in all cases anyway. Some apps do it some don’t.

I wrote a Tool (MIDI plug-in for Bars & Pipes Pro) that could do just that a long time ago. It would, in real time, shorten even MIDI note by a set number of ticks. It solved many problems back then. I wrote another one that would fix all overlapping notes. That one fix a lot more serious problem. I know that most synths didn’t have a problem with these but one or two (or whatever) were terrible about stuck and lost notes. These tools were created out of necessity.

Wow I sure hope this fixes the problem. I also reported these same issues with MIDI a while back. I have had this issue for a long time now, mainly with RGC Audio VSTI’s (sfz and triangle II).

However … note that a change in this functionality could break some songs, depending on the synth. I know with Crystal for instance, if you have an evolving patch, and two notes butt up against eachother in the paino roll, they evolution will keep going, whereas any break would cause it to start over.

I do think by default however, notes that butt up agains each other should not overlap, and any exceptions should be changed manually.

I would love to see this get incorporated into a future build. :D

<!–QuoteBegin>

Quote
However … note that a change in this functionality could break some songs, depending on the synth. I know with Crystal for instance, if you have an evolving patch, and two notes butt up against each other in the paino roll, they evolution will keep going, whereas any break would cause it to start over.

This is true, but the fix probably should NOT be to change events as they are in the MIDI file. In other words don’t fix files on the fly. It will break things in really odd ways, just as this example explains.

The fix is to make end quantized and step entry end quantized notes be one tick shorter than they are now. This kind of change will not fix any existing MIDI file playback issues, but it will allow new MIDI files created in n-Tracks to not have this problem. As I said, some apps do this already - some don’t. Yet, there are MANY existing MIDI files that have this problem or much worse, especially old MIDI files.

How to handle intentionally overlapping notes is a totally different issue. The MIDI editor should allow this if the author wants to do it. There could eventually be a toggle option to disallow note overlap, with an automatic fix if desired. This can be added to the wish list. I’m not expecting it any time soon.

MAYBE there could be an on the fly option (can toggle it) to do this, but that would be more difficult from Flavio’s end, and may only mask problems in existing files. MIDI files really should be played as is, so I’m sort of against this as a default for sure. (Of course I did write a tool to do it long ago.)

FYI: When I was having problems with sfz a while back this was not the issue.