Fender Studio Pro 8.0.1 - Discussion Thread

[Pianistofthemoon]

Ho visto diverse persone menzionare questo problema. Non riesco a replicarlo. Ho 4 monitor. Uno è 2K, gli altri sono 1080p, ma uno dei monitor 1080p è orientabile in verticale anziché in orizzontale. Non riesco a replicarlo su nessuno dei miei monitor.

This is another problem not midi channel problem in live show page

 

[Vocalpoint]

I've seen several people mention this. I can't duplicate it. I have 4 monitors. One is a 2k, the others are 1080p, but one of the 1080p monitors is portrait rather than landscape. I can't duplicate this across any of my monitors.

This whole process is dictated by the OS - from resolution to what is being dragged where.

Highly unlikely that Studio Pro is designed (OR tested) to navigate infinite combinations of resolutions it might encounter in the real world nor can it control how a plugin (like say Battery) will behave to being dragged around either.

None of these products are designed for 4K and none should be expected to operate issue free at that resolution.

If one has their resolution set to standard HD (1920x1080) across the board (espeically when it comes to Windows if that's your thing) - pretty much guaranteed there will be no issues.

VP

 

[Pianistofthemoon]

I have a monitor 1080p nothing problem with plugin my problem not show midi channel change on track live show page this is a problem inside costruction studio one pro 8

 

[Number6]

This whole process is dictated by the OS - from resolution to what is being dragged where.

Highly unlikely that Studio Pro is designed (OR tested) to navigate infinite combinations of resolutions it might encounter in the real world nor can it control how a plugin (like say Battery) will behave to being dragged around either.

None of these products are designed for 4K and none should be expected to operate issue free at that resolution.

If one has their resolution set to standard HD (1920x1080) across the board (esp. when it comes to Windows if that's your thing) - pretty much guaranteed there will be no issues.

VP

My post is nothing to do with 4K and NI plugins being too small etc, I acknowledged right at the beginning of the video that this is Native Instruments code at issue for it being too small (I was waiting for someone to comment about that, we all know NI haven't been great at updating their UI's for 4K). I'm not changing my monitor resolutions, they work fine for me.

The issue is the Studio Pro plugin window (container) that contains the plugin itself, not the actual plugin. That is Studio Pro code (the actual window container itself).

The real issue is when the plugin moves from one screen to another, Studio One needs to refresh the window dimensions correctly, and that doesn't happen in the case of this plugin, and it should.

The thing is that Studio Pro does have the code to resize the plugin window, and it works correctly, it just doesn't get triggered at the right time or it's using some other code. Look at my video again at 40 seconds, when I flip a tab in the S Pro plugin Window UI, from one plugin to another, Studio Pro correctly resizes the plugin window. So that just needs to happen automatically without a workaround.... it's just not being triggered when moving to another monitor. Again this is the window container for the plugin doing this (Studio Pro), NOT the actual plugin itself, that's being hosted. The funny thing is that the window does get refreshed/redrawed after being moved from another monitor, but it isn't doing it right, but (as stated earlier) the click tabs workaround I used proves Studio One can do it right.

So it is a refresh issue with the window that hosts the plugin itself, and that's Studio Pro code .

 

[Vocalpoint]

The issue is the Studio Pro plugin window (container) that contains the plugin itself, not the actual plugin. That is Studio Pro code (the actual window container itself).

The only issue is - your assumption that just because a plugin is being hosted by SP - that SP has some say in what it can actually do/not do to the plugin UI all the while trying to handle the rendering/re-rendering/resizing or whatever else is really going on when you are dragging things from one completely different resolution to another.

Do remember that SP itself - is being "hosted" - by Windows - and Windows controls everything we see on screen.

How objects are rendered/drawn. How these objects interact with OS scaling - with HiDPI settings - and all the other technical resolution stuff going on when you start dragging windows across boundaries - all of it needing to be calculated on the fly (and managed by) the OS.

And this gets even uglier when you encounter a non-sizeable antique like Battery. Honestly - I cannot fault any DAW for not knowing what to do with a situation this complex (different monitors with different resolutions and response times)

VP

 

[Number6]

The only issue is - your assumption that just because a plugin is being hosted by SP - that SP has some say in what it can actually do/not do to the plugin UI all the while trying to handle the rendering/re-rendering/resizing or whatever else is really going on when you are dragging things from one completely different resolution to another.

Do remember that SP itself - is being "hosted" - by Windows - and Windows controls everything we see on screen.

How objects are rendered/drawn. How these objects interact with OS scaling - with HiDPI settings - and all the other technical resolution stuff going on when you start dragging windows across boundaries - all of it needing to be calculated on the fly (and managed by) the OS.

And this gets even uglier when you encounter a non-sizeable antique like Battery.

Honestly - I cannot fault any DAW for not knowing what to do with a situation this complex (different monitors with different resolutions and response times)

VP

This is the point ->>>> The code is already there, Studio Pro can easily refresh the window size correctly. So when you are talking about all the complexities etc etc, it's already been done, Fenders code works! It simply not being executed when their plugin host window is being moved from one window to another. And it's nothing to do with the plugin, the plugin is still staying the same size, it does not need to be rerendered at all (nor is it). It's just the window that contains it that's the issue and NOT the plugin.

Maybe another video will make things clearer.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Vocalpoint]

This is the point ->>>> The code is already there, Studio Pro can easily refresh the window size correctly.

I understand what you want. And thank you for the video.

Still do not think this has anything to do with SP however. And everything to do with how Windows is dealing with that plugin window when you drag it over to a smaller resolution.

Have you actually tested this dragging a more modern plugin that CAN be resized?

FWIW - I have seen this type of thing for years in Windows - and in situations that have nothing to do with any DAW.

Be very surprised if Fender takes this up - but one can always hope.

VP

 

[Number6]

I give in.

I've clearly demonstrated that it's a simple window resize issue in Studio Pros plugin host window in the last video.

Studio Pro simply needs to trigger the exact same code it uses when flipping between one plugin and another, and that need to trigger automatically when the window arrives from one monitor to another, and that's just a few lines of code.

When studio Pro actually does this, it does it 100% correctly, I clearly demonstrated it in the video by flipping plugins in that window. This is absolutely nothing to do with the plugin, the plugin size still remains exactly the same (it just looks bigger because it's now on a monitor with a smaller resolution size and that's fine).

 

[BobF]

I give in.

I've clearly demonstrated that it's a simple window resize issue in Studio Pros plugin host window in the last video.

Studio Pro simply needs to trigger the exact same code it uses when flipping between one plugin and another, and that need to trigger automatically when the window arrives from one monitor to another, and that's just a few lines of code.

When studio Pro actually does this, it does it 100% correctly, I clearly demonstrated it in the video by flipping plugins in that window. This is absolutely nothing to do with the plugin, the plugin size still remains exactly the same (it just looks bigger because it's now on a monitor with a smaller resolution size and that's fine).

A: This deserves it's own thread for focus & visibility and hopefully confirmations from other users
B: You should document an easy to follow set of steps that reliably demonstrate the problem and submit via support.

Code problems will never be solved in this forum.

 

[Vocalpoint]

A: This deserves it's own thread for focus & visibility and hopefully confirmations from other users
B: You should document an easy to follow set of steps that reliably demonstrate the problem and submit via support.

This.

Without consistent confirmation from a reasonable variety of use cases - one uinque instance of a problem does not make it an issue (or a bug)

VP

 

[Number6]

A: This deserves it's own thread for focus & visibility and hopefully confirmations from other users
B: You should document an easy to follow set of steps that reliably demonstrate the problem and submit via support.

Code problems will never be solved in this forum.

I have two videos posted here, I can't see any other way of demonstrating it more clearly, it's a very simple issue.

The code to resize a Window (which they already have and it works fine as demonstrated) is not being triggered (or not being triggered correctly or using different code) when a plugin is being moved from one monitor to another with different screen resolutions. This issue will not be reproducible on monitors with same size resolutions.

It may be specific to certain plugins, but it isn't the plugin that's the issue, because as I've demonstrated, Studio Pro is perfectly capable of resizing the window that contains the plugin to the correct dimensions. At all times the plugin itself stays the same resolution and does not need to be rerendered, it's just the host window.

I will send them to support.

 

[BobF]

I have two videos posted here, I can't see any other way of demonstrating it more clearly, it's a very simple issue.

The code to resize a Window (which they already have and it works fine as demonstrated) is not being triggered (or not being triggered correctly or using different code) when a plugin is being moved from one monitor to another with different screen resolutions. This issue will not be reproducible on monitors with same size resolutions.

It may be specific to certain plugins, but it isn't the plugin that's the issue, because as I've demonstrated, Studio Pro is perfectly capable of resizing the window that contains the plugin to the correct dimensions.

I will send them to support.

You could also start a new thread here and ask for confirmations. BTW, some folks work better from a set of steps than watching videos. Up to you.

 

[Number6]

You could also start a new thread here and ask for confirmations. BTW, some folks work better from a set of steps than watching videos. Up to you.

I've done QA jobs before for software development houses, and yup I entirely understand the necessity of steps to reproduce. However in this case a brief video says a thousand words and clearly demonstrates the problem.

Anybody here who has plugin without a rescalable UI (that look tiny on 4K screens, like NI battery 4 and a whole range of old NI plugins), who has two monitors set at different resolutions (one of them 4K perhaps) should be able to repro on Windows.

Regardless I won't waste any more time on this and I'll take it out of the forums hands and send to support.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies