Is it plausible that Stu.one's midi issues comes from the fact they are converting it to their own midi protocol ( look mum no midi ) which is used for virtual instruments ?
Ten years of silence from presonus part regarding this issue makes me believe the problem is deeply routed in the code ( their take on midi ) and can't be fixed that easily , hence the 10 years of radio silence .

Just speculating

https://s1manual.presonus.com/Content/F ... o_MIDI.htm

warddejager wroteIs it plausible that Stu.one's midi issues comes from the fact they are converting it to their own midi protocol ( look mum no midi ) ,

Not this particular issue. I don’t understand how it’s productive to come in every thread that involves midi and suggest this. Also, since I assume you’re mentioning multiple issues that weren’t touched on in this thread- you posted a lot of issues before and many of them were reported and fixed.

Ten years of silence from presonus part regarding this issue makes me believe the problem is deeply routed in the code

The “silence” is likely due to the fact that this is not an “issue” so much as a difference of opinion. It is some people’s opinion that they should be able to monitor live input at larger-than-average buffer sizes and have no jitter.

I provided my tests above, niles did some tests, lots of tests, admiral did a lot of testing. So far it looks like the discussion of jitter at 64 (a size at which I think many people Monitor live input) is basically academic.

Can you exacerbate the issue by monitoring at buffers of 512 and greater? Yes, but previous threads indicate that’s a trade off for achieving lower overall latency.

robertgray3 wrote

warddejager wroteIs it plausible that Stu.one's midi issues comes from the fact they are converting it to their own midi protocol ( look mum no midi ) ,

Not this particular issue. I don’t understand how it’s productive to come in every thread that involves midi and suggest this. One issue are a time, btw- you’ve posted a lot of issues before and many of them were reported and fixed.

Ten years of silence from presonus part regarding this issue makes me believe the problem is deeply routed in the code

The “silence” is likely due to the fact that this is not an “issue” so much as a difference of opinion. It is some people’s opinion that they should be able to monitor live input at larger-than-average buffer sizes and have no jitter.

I provided my tests above, niles did some tests, lots of tests, admiral did a lot of testing. So far it looks like the discussion of jitter at 64 (a size at which I think many people Monitor live input) is basically academic. As for the jitter at 512 and up, I’d love to hear from someone who is actually monitoring audio at 512 and up and to know how they can even play accurately with that much round trip latency, never mind jitter.

Why is this not a midi issue , and not related to Look mum no midi ?
Do you have some insider info , please share if you do .
Triggernig impact xt from a yamaha rm1x ( bumbelbee's video )requires midi , no ?
And secondly , no not all my midi issues are resolved , the verry annoying issue of waiting for a win update to resolve it , only 2 other persons I know of have the issue .
When a thread is locked it doesn't mean it's resolved .
And yes , I posted a lot of issues which were actual bugs .

robertgray3 wroteAt the end of the day, audibly is what me and my clients are concerned about, so I do audio in at 32 and MIDI in at 64.
...
When is monitoring at 256 and above useful, though?
...
Great picture! At the risk of sounding callous, being able to see the results I heard only justifies my indifference to this issue.

It's very good to have a baseline for Mac, though, so if someone's results deviate from the results you and I got they can start looking into other issues being at play.

You are truly insufferable. How about working at 96k where such buffer settings still provide plenty fine working latency. Oh and I'm also a professional, glad you get paid too.

robertgray3 wroteI provided my tests above, niles did some tests, lots of tests, admiral did a lot of testing. So far it looks like the discussion of jitter at 64 (a size at which I think many people Monitor live input) is basically academic. As for the jitter at 512 and up, I’d love to hear from someone who is actually monitoring audio at 512 and up and to know how they can even play accurately with that much round trip latency, never mind jitter.

I am not a fan of this line of thinking, because I believe that the software should work predictably, as documented, regardless of the perceptibility of the issue. Especially so since perceptibility varies from user to user and situation to situation.

Even in the scenarios where you can't audibly notice the jitter, having jittery feedback will undoubtedly affect your performance at some level. As musicians we train ourselves to respond to very small changes in tempo, pacing and timing. Sometimes it's a band mate, sometimes it's a weird effect, sometimes it's the DAW.

I said before in this thread that I started this whole investigation because I was independently contacted by users working with normal settings (low-latency setups) that perceived the timing differences but were unable to quantify it. For me this is evidence enough alone that it's possible to be affected by it, even if the users were unable to communicate much other than "Something is off..." and provide a poorly designed or fuzzy test.

Another consideration is that responding with some form of "Well I can't hear it" comes off as dismissive. Even if only a small percentage of users are affected by it, and a smaller percentage can hear it, it's bordering on insulting to dismiss their frustrations. Every single one of us encounters issues that a majority of users don't deal with, and I think it's poor form to invalidate those problems because it doesn't affect someone else.

I'm writing this message specifically because of users discussing this thread outside this forum that feel like their concerns are being dismissed by comments like what I quoted.

I know that you've been trying to help and have run some tests with us and talked through things, and I'm grateful for that, but please be aware of how it piles frustration upon frustration to have it implied that an issue isn't valid because "It doesn't affect me" or that it's an unusual scenario.

robertgray3 wrote
The “silence” is likely due to the fact that this is not an “issue” so much as a difference of opinion. It is some people’s opinion that they should be able to monitor live input at larger-than-average buffer sizes and have no jitter.

.

You actually believe what you just wrote ?

Rasi wroteYou are truly insufferable. How about working at 96k where such buffer settings still provide plenty fine working latency.

The highest I enjoy tracking at in 96 is still around 128 which is still below where the Admiral said the monitoring jitter reached audible territory. Just tested it at 96. I don’t normally work this way but thought I’d go ahead and test it since you mentioned it.

admiralbumblebee wroteEven if only a small percentage of users are affected by it, and a smaller percentage can hear it, it's bordering on insulting to dismiss their frustrations.

I gave you guys my feedback as an end user. I’m not trying to provoke you guys- sorry if my experience is somehow insulting to you personally, or the users you are concerned about.

Mine is the perspective of someone who performed the same tests as you and decided whatever compromises were made in this part of the program are not affecting my workflow. I understand how it feels to have people say that and not perform the tests, so I went ahead and did them for you.

I know text doesn’t convey this well at all but although I truly get that it hurts your guys’ feelings to hear that, it’s important to have a variety of users weigh in. Otherwise we only hear from those for whom the current audio engine is deemed unacceptable. A one-sided debate is not typically productive.

warddejager wroteYou actually believe what you just wrote ?

Every word of it Re-read niles’ posts and the threads he linked in this and the other thread about jitter (it’s probably still on the front page as of right now). Plenty of info in those threads about this, and luckily not much speculation.

Cheers and good luck, hope my video helps all you guys compare results.

Latency figures vary. For me on my Mac system (Focusrite Clarett over thunderbolt) I am only seeing 3.7 mS at 128 samples buffer and 10mS at 512 samples buffer. 1.16 mS at 16 sample buffer. Fast.

Ok - so I'll chime in my input here. I've read through (most of) the thread and I understand where both "camps" are coming from:

1. You have the purists, who believe that the recording of the data/music should be both accurate and predictable.
2. You have the others, who believe that the software should be accurate, but there is a point of limited return or reasonableness where it becomes ONLY academic (and likely not musical).

I probably fall somewhere between 1 and 2. I am a drummer. I have very little tolerance for latency, so I won't perform with a VST drum instrument. I have yet to trigger one directly that is satisfying or even barely acceptable to me. I'm a decent drummer, but not amazing and I've heard plenty of "less decent" drummers extol the virtues of how much better VSTs are than "drum modules" but then play and have no observable reason to even be contributing to a conversation about accuracy or timing.

I have always been sensitive of my recordings being "off" from what I perceived that I played. Typically, I reboot the computer and feel a little better about things, but have always felt the need to do some amount of MIDI tweaking to get the playback to match what I FEEL like I recorded. Fortunately, it's generally just a small bump of the whole recording by a few ms and some spot fixes along the way because I'm an imperfect player.

I just ran a quick test at my preferred settings in Studio One of 64 Samples with "minimum" dropout protection. Based on the recording and some measurements, I then adjusted my MIDI settings to put in a -5ms Record Offset, with Audio set at 0ms Record offset. I've not gone through some of the more rigorous tests. I just wanted to get a simple baseline for ME.

After the adjustment, I recorded a series of 5 snare hits with a mic on my drum pad and a midi recording of my Pearl Mimic Pro. The end result is a small amount of jitter, but likely something I can live with for my level of playing - forget about the other instruments that are far from as good as my drumming.

So, my results in this SIMPLE test were basically that my audio and MIDI were within 1ms (forward or behind) of the audio (probably less than 2ms of total jitter). I don't ever change to Green or Blue recording, I don't generally change from Minimum Dropout protection, and I don't generally change from 64 samples, since my system can handle that from end to end without losing its mind - and if I do change that, it's not for recording, it's just for playback of already recorded and converted from midi to audio.

For what it's worth, I have a Presonus Studio 18|24 Audio Interface, USB
I am running on Windows 10 Pro (1903)
I have an MSI motherboard with an Intel i7 8700k, not overclocked and 16gb of RAM
My system is less than optimal since I use it for much more than a DAW. I do IT support on this as well as it being my main PC for everything else. At this moment, the system has been up for 3 days and 1 hour and I did nothing to setup for the test, since that's my normal mode of recording as well.

I hope that this "super simple" update is useful in your data collection somehow. In the end, I understand both #1 and #2 at the top of this post. #1 is right in that it should record what you put into it and #2 is right that there is a diminishing return and for MOST people, the little inconsistencies will produce perfectly listenable music that likely exceeds the talent and timing perception of all who will listen to it, and likely those who recorded it.

robertgray3 wroteIt is some people’s opinion that they should be able to monitor live input at larger-than-average buffer sizes and have no jitter.

It's a valid opinion for some use cases.

Eg., external MIDI sequencer controlling a VST plugin, routing the output of that plugin through external hardware effects then back into S1. If its a resource heavy plugin then you might need a larger-than-average buffer in order to record without drop-outs.

warddejager wroteIs it plausible that Stu.one's midi issues comes from the fact they are converting it to their own midi protocol ( look mum no midi ) which is used for virtual instruments ?(...)
Just speculating

Why not simply test it instead of speculating? Establish a MIDI loopback and test Studio One and product X and look if the results differ?

admiralbumblebee wrote

niles wroteBTW I see an output latency of 216ms with a buffer size of 64 ms in that video.

I have 4 screen capture softwares which all have various limits regarding audio capture unfortunately. Audio loopback also presents some issues.

They have a combination of: locked at 48khz, have excessive output latency or they have limited buffer size options.

I need to do some research on how to capture something under similar audio conditions as your test.

Please do. Make your setup as simple (average) as possible. @robertgray3's video showed what to expect, if it works different we should zoom in to your rig to find out what is causing it.

admiralbumblebee wroteI'm writing this message specifically because of users discussing this thread outside this forum that feel like their concerns are being dismissed by comments like what I quoted.

I know that you've been trying to help and have run some tests with us and talked through things, and I'm grateful for that, but please be aware of how it piles frustration upon frustration to have it implied that an issue isn't valid because "It doesn't affect me" or that it's an unusual scenario.

I'm purely looking at what I can measure because it's impossible to say what happens at the rigs of the users that run into issues. I can think of a lot of scenarios that can cause additional deviations or get in the way while playing (you proved one yourself with that setup).

robertgray3 (macOS) and I (Windows) both showed in a video how Studio One itself is supposed to work under normal circumstances when it comes to deviations due to buffer cycle changes. You can hear it, measure it, do it yourself (the test is included), whatever you like.

I explained to you that below 256 samples Studio One does not use a safety buffer (deviations in monitoring) and from 256 and up it does (no deviations), at the cost of some additional latency. That's how it's currently designed for Windows and macOS. If you like that or not is a totally valid and comprehensible opinion. After all there are pros and cons in both solution to work with latency.

I also read some comments on your site and Youtube and you are literally telling people I don't understand the issue. Apparently you have a lot of credits with your "followers" because your opinion is worth more to them than the facts we try to show here. That's a tricky situation if you want to stick to facts.



Back on topic. Additionally this video (song file is attached) gives a nice inside in how the buffer system operates in real time.
As you can see there are deviations. With a 128 samples/44.1kHz setting the average latency is roughly 7 ms and the maximum deviation is ~3ms (43% of the average latency).
With a 1024 samples/44.1kHz setting the average latency is roughly 50 ms and the maximum deviation is ~2ms (4% of the average latency).

Orange is the our constant (audio), green is the monitored signal.

niles wroteI also read some comments on your site and Youtube and you are literally telling people I don't understand the issue. Apparently you have a lot of credits with your "followers" because your opinion is worth more to them than the facts we try to show here. That's a tricky situation if you want to stick to facts.

I completely agree with you. I forgot about that single comment on my website, which I'll update to refer to a link to this discussion. There was also a comment on youtube that gave information that contradicted the results which I (and you below) can easily reproduce. I'll also update that with a link to this discussion.

I think it's pretty obvious that I constantly repeat that people should not trust random people on the internet and to test themselves. I can't stand when people take someone's word for it in a situation where a self-test is simple.

The side-effect of people (unfortunately) blinding trusting me because I wrote an article instead of a private ticket is a discussion that I'd be glad to discuss elsewhere with you if you wanted.

EDIT: I have pinned comments linking to this discussion in reference to my response that I believe are incorrect (which I think is a murky issue now), and I'll update the article with a link to this discussion after lunch.

niles wrote

Back on topic. Additionally this video (song file is attached) gives a nice inside in how the buffer system operates in real time.
As you can see there are deviations. With a 128 samples/44.1kHz setting the average latency is roughly 7 ms and the maximum deviation is ~3ms (43% of the average latency).
With a 1024 samples/44.1kHz setting the average latency is roughly 50 ms and the maximum deviation is ~2ms (4% of the average latency).

Orange is the our constant (audio), green is the monitored signal.

phpBB [video]

I'll be working on this later today, however even your test shows jitter at all buffer sizes. The values differ, but the behaviour still exists. There are products with extra buffers that have significantly less variation or are sample accurate (MIDI timing resolution a separate topic I suppose...), so I believe that even your examples show that this is erroneous behaviour in the situation where S1 switches to using an extra buffer.

At the very least I'll run the test with no audio and a normal audio device. The clever use of scope there should demonstrate it clearly with no audio if it comes to that.

If you want as well, I can schedule a live call or stream with you and we can work on this in realtime on my system to iterate through ideas quickly.

I made the post/video/comment updates as described above.

Here's a video of the test project at 44.1khz, with no changes except:

• - Adjust I/O as indicated
• - Increase size of Scope window
• - Increase Time Scale of scope

Buffer sizes 512 and up were not visible with the delivered scope scale. I set it to 16ms time scale and measured the approximate jitter range on screen during playback.

I avoided any audio capture drivers and only used native UA Thunderbolt audio drivers.



As with all previous tests, the amount of jitter consistently changes with buffer size. Each doubling of buffer size also doubles the amount of jitter on this system.

I'll repeat the test on Windows with the same setup shortly.

admiralbumblebee wroteHere's a video of the test project at 44.1khz, with no changes except:
(...)

phpBB [video]

Great, this exposes the issue and difference quite well. This is not the behavior I measured nor would expect.

admiralbumblebee wroteI'll repeat the test on Windows with the same setup shortly.

That would be good to narrow it down and to see if it's related to the OS.

@robertgray, if you have the time, could you run that Easy_Buffer_Jitter_Test_3.zip on your Mac too?

This is great reading, thankyou for your efforts.

Windows Notes:

~1.6ms Jitter consistently.

DP size does not affect it. Buffer size does not appear to affect it.

In DP modes with LL available, turning LL on/off does not appear to affect it.

I did encounter something strange though: With Maximum DP, LL on and buffer sizes below 2048 (1024 and lower), the scope did not work for track A. Recording the output gave some strange results where the first and second note were close together and the rest were evenly spaced.

Same result for DP at High, with LL on and buffers below 1024.

Something else that I discovered here...

On macOS with DP protection enabled (Maximum) AND LL turned off, there is zero jitter for buffer sizes from 32-1024. It's sample perfect.

Buffer size of 2048 and it goes wonky.
Turn on LL and it goes wonky.

The "goes wonky" (scientific term) point for DP Medium is 512. DP High cutoff is 1024.

I did not discover this in any of my original tests. This is not the default settings of S1.

This means that so far:

• Cross platform behaviour is inconsisent.
• Windows always has minor jitter (in my tests, and in Niles videos)
• macOS performs vastly differently depending on Studio One settings, and some combinations demonstrate that sample accurate live playback is possible (with added latency of course).

niles wrote

admiralbumblebee wroteHere's a video of the test project at 44.1khz, with no changes except:
(...)

phpBB [video]

Great, this exposes the issue and difference quite well. This is not the behavior I measured nor would expect.

admiralbumblebee wroteI'll repeat the test on Windows with the same setup shortly.

That would be good to narrow it down and to see if it's related to the OS.

@robertgray, if you have the time, could you run that Easy_Buffer_Jitter_Test_3.zip on your Mac too?

Sure, remind me of the difference between this test and the last one?

Same practical results for me - I see the jitter at 64 and it becomes audible around 256.

Are you saying it should have less jitter (%) the higher the block size goes?

admiralbumblebee wroteI did encounter something strange though: With Maximum DP, LL on and buffer sizes below 2048 (1024 and lower), the scope did not work for track A.

I noticed this too. I'm pretty sure there are send restrictions with a dual buffer.

admiralbumblebee wrote~1.6ms Jitter consistently.

Your video said "broken". Is ~1.6ms of jitter on Windows "broken", or is it safe to say that we're basically only talking about macOS at this point?