# Studio One Complaint Thread



## FireGS (Jun 28, 2022)

Not sure if one of these already exists, but I'm somewhat at my wits end with some super basic functionality either broken, or non-existent inside Studio One. I've made support tickets, threads on the Presonus forum, contacted 3rd parties to poke Presonus about these issues and just getting nowhere after months and months -- so now I'm going to bitch about it here.

Serious issue: Studio One doesn't handle plugins (VST) either well, or properly, or both (Win 10). I have a Tegeler Creme RC that is a hardware compressor/EQ that's digitally controlled by a VST over ethernet. All of the knobs can be automated by track automation. I have some output knob automation programmed. It responds during playback, but rendering in real time with Studio One, the knob just stays at the last value it was at, never resets, doesn't change over time as programmed either. Weirdly enough, if you shake the "rendering" window while its rendering, the knobs suddenly come to life. If I release the window, the automation stops again.



Apparently this bug has plagued Studio One for *YEARS* and hasn't been addressed or even acknowledged by Presonus officially - as far as I can tell. It's not just this one plugin, either. A few others have this issue. 

So I've got this nice $2,000 box that I can't realllly use the way it was supposed to be used because I chose Studio One. Great. 

I reached out to Tegeler and Presonus about this and Presonus said its probably Tegeler's issue, and Tegeler said it's definitely Presonus' issue. Haven't heard back in months. I was able to figure out some more technical details about why this was happening using Wireshark (since its ethernet data) and reopened my ticket with Presonus based on this new information that might help their team, and they replied, rather flippantly, "Like I said, we've already logged this issue." Cool attitude, sorry for trying to help.

The reason this is a problem for me and others is that we can't really trust that Studio One is actually applying the automation curves it says it is with plugins. There's a whole thread on their forums about it: https://forums.presonus.com/viewtopic.php?f=151&t=44763

Issue (or rather, omission) #2: There's no way to freeze/bounce tracks in realtime. Studio One has this really nice feature that you can bounce MIDI instruments to Audio while saving the instrument's settings and unloading it to save resources. You can also choose not to render Insert FX and keep them live on the new audio track. Really great for tweaking later. The problem is if you want to use any external hardware. You have to use their Pipeline XT plugin as an insert -- but there's no way to "render track to audio" with "realtime" rendering. Any external hardware piped in through Pipeline XT is just silent because it does an offline render. 

Why is there *still no track freeze with realtime audio?* If I want to use anything like a hardware compressor or EQ on any one track, I have to render it out, or record the track to a new track which doesnt save any of the other insert FX. I'm using Tegeler and WesAudio devices with VST recall so that if I want to use a compressor or EQ on a single track I can load the controller plugin on the track -- process the audio -- render it -- then freeze the inserts so that I can use the same compressor on another, or potentially ALL of my other tracks. Not a thing in Studio One. Sweeeeet.

Issue #3: I still cannot wrap my head around why they've implemented the MIDI CC assignment system the way they have. In every other daw you choose a track, assign the MIDI controller, and your hardware controllers mapped CCs just work. CC1 is assigned to the modwheel and it just works. No, in Studio One, I have to hope that the VST Instrument I'm using responds to the Studio One controller assigner. If it doesn't, enjoy like 30 more steps to maybe get it working. Mind boggling why this thought to be a good idea. 

Issue(s) #4: The amount of crashes is too damn high. Any time I try to close a project gracefully, the whole DAW just crashes out and reboots itself saying "Oops, Studio One had an issue". Or sometimes when having a plugin window open on a second monitor freezes the whole DAW requiring a reboot? 

Issue #5: This was a fun one I just discovered recently. If you go to File > Save to New Folder and move your project to a new location, it only copies the files that are "used in the pool", doesn't copy over Cached files, or most importantly MELODYNE EDITS. I had a GIANT project with 130ish audio tracks that I used Melodyne on, saved the project to a new folder for organization purposes and next time I opened it -- bam, all edits gone. *Not only that, but it also deleted the files from the old location.* Thank god I had backups of backups of backups and was able to recover the work I did. 


I'm sure I could think of more, but those are the most glaring. I'm really considering switching DAWs but I'm in the middle of a big project and don't have the ability to switch the whole project over to a new DAW that I don't know. I wish someone at Presonus would look at these basic usability issues. I don't know what else to do at this point. Some of these things are real deal breakers. I can deal with crashes occasionally, but not handling VSTs like every other DAW simply "because"? Killing cached files and edits because "reasons"? Shitty attitudes from support? Ugh.


----------



## dcoscina (Jun 28, 2022)

I’ve had a lot of crashes since the last update on Mac OS M1, mostly with VSL Synchron player…


----------



## SonicMojo (Jun 28, 2022)

"The amount of crashes is too damn high. Any time I try to close a project gracefully, the whole DAW just crashes out and reboots itself saying "Oops, Studio One had an issue"

Fair enough to say that you are having issues and it certainly seems that you have some unique items here (Tegelar) that probably represents a very rare issue.

However to suggest that S1's "crash ratio" is too high - is a unique situation for all of us. I for example - haven't had a crash for years (if ever) and as of this writing - I have 1023 plugins in play.

Need to temper the conversation as I have seen many a user have some oddball VST that never works right and the first thing they do is blame the DAW. 

Me - I would instantly ditch a suspect VST before bailing on my DAW - that is for sure.

My two cents.

Sonic.


----------



## FireGS (Jun 28, 2022)

SonicMojo said:


> "The amount of crashes is too damn high. Any time I try to close a project gracefully, the whole DAW just crashes out and reboots itself saying "Oops, Studio One had an issue"
> 
> Fair enough to say that you are having issues and it certainly seems that you have some unique items here (Tegelar) that probably represents a very rare issue.
> 
> ...


Yeah, I wish I could. I've invested a huge amount of time into S1 and a huge amount of money into Tegeler. I'm kinda stuck either way I go. The kicker is that other DAWs I try have no issues with Tegelers VSTs whatsoever. In fact, of all of the free DAWs and Demos of DAWs I've tried, *NONE* have the issue that Studio One does. At this point I'm very certain that with the Tegeler equipment, it's a Studio One issue. 

The issue seems to be that the render function is disallowing network traffic. I see http requests via Wireshark when I press play heading from my machine to the Creme's IP address (it's HTTP SENDing JSON data), but when I render, theres no traffic from my machine to the Creme at all. Not even SYN/ACK data -- it's just as if the data isn't flowing from Studio One. When I shake the window, suddenly HTTP SEND data flows again. Then it stops when I let go of the window.


----------



## SonicMojo (Jun 28, 2022)

FireGS said:


> Yeah, I wish I could. I've invested a huge amount of time into S1 and a huge amount of money into Tegeler. I'm kinda stuck either way I go. The kicker is that other DAWs I try have no issues with Tegelers VSTs whatsoever. In fact, of all of the free DAWs and Demos of DAWs I've tried, *NONE* have the issue that Studio One does. At this point I'm very certain that with the Tegeler equipment, it's a Studio One issue.
> 
> The issue seems to be that the render function is disallowing network traffic. I see http requests via Wireshark when I press play heading from my machine to the Creme's IP address (it's HTTP SENDing JSON data), but when I render, theres no traffic from my machine to the Creme at all. Not even SYN/ACK data -- it's just as if the data isn't flowing from Studio One. When I shake the window, suddenly HTTP SEND data flows again. Then it stops when I let go of the window.


Fair enough - but to expect ANY DAW to be able to correctly navigate every plugin ever made by every vendor is a bit fair fetched.

If other DAWs do not present the issue with Tegelar (BTW - never ever heard of this VST until this thread) - then I think the solution is clear. Drop S1 and use a DAW that gives you less hassle factor. 

Cheers!

S


----------



## FireGS (Jun 28, 2022)

SonicMojo said:


> Fair enough - but to expect ANY DAW to be able to correctly navigate every plugin ever made by every vendor is a bit fair fetched.


Not exactly. VSTs are built from an API, Steinbergs. If it can be done in a VST, the host should support it. If it's not, but all other DAWs do -- the blame is squarely on the single DAW at issue.


----------



## SonicMojo (Jun 28, 2022)

FireGS said:


> Not exactly. VSTs are built from an API, Steinbergs. If it can be done in a VST, the host should support it. If it's not, but all other DAWs do -- the blame is squarely on the single DAW at issue.


If I had a nickel for every so called "VST" that actually follows Steinbergs API....

Trust me - Steinbergs API has a huge amount of latitude as does the supposed skill of said vendors programming these plugins - resulting in some superb work, some horrific work along with lots inbetween - whilst ALL VSTS are supposedly following the same song sheet - they are most definitely not. 

I can name about dozen vendors that truly knock it out of the park everytime with all their products and actually do honor the VST API spec while hundreds more out there should just stop what they are doing and get into another line of work - pronto. 

Not sure where Tegelar fits into the grand scheme of VST programming but if you are hardcore on keeping it and lay the blame on the DAW - move onto another. 

I am simply another random S1 user out here with a crap load of plugins from across the spectrum and I have no issues whatsoever. 

Sonic.


----------



## easyrider (Jun 28, 2022)

What version of windows Is it ? What build?

what version of S1

cheers!


----------



## FireGS (Jun 28, 2022)

easyrider said:


> What version of windows Is it ? What build?
> 
> what version of S1
> 
> cheers!


S1 5.5.2, and Win 10 21H2 (build 19044.1766)


----------



## NuNativs (Jun 28, 2022)

Cubase.


----------



## FireGS (Jun 28, 2022)

NuNativs said:


> Cubase.


It's on the shortlist... the *very* short list.


----------



## rrichard63 (Jun 28, 2022)

I've noticed in the past that Presonus seems to be somewhat selective about which bug reports and feature requests they choose to respond to, and which ones they choose to ignore. I have no idea what their criteria are. It would make sense for one criterion to be a guesstimate as to the number of users affected, but I don't know whether that's the case.

If I were @FireGS in this situation, and assuming that the reason he needs to control the Creme RC from within Studio One is automation, I would (1) find a way to finish my current project using software compression and EQ instead of my beloved hardware, and then (2) change DAWs. If he doesn't need automation of the hardware's parameters, why not just twirl the physical knobs?

If I were Presonus, I would try to do a more consistent job of communicating to users about the status of bug reports and feature requests.


----------



## FireGS (Jun 28, 2022)

rrichard63 said:


> If he doesn't need automation of the hardware's parameters, why not just twirl the physical knobs?


So the hardware was kinda sold to me on the basis that I *can* automate it. For now, I've been using it like a straight compressor. (But if I had known this, I could have spent $500 less on the non-RC version....)


----------



## GtrString (Jun 28, 2022)

Zero crashes on mac Big Sur, and Im sick of having a daw that can’t make me even consider other daw’s. What’s wrong with GAS!!?


----------



## Lukas (Jun 28, 2022)

Okay, so your plug-in does not work properly? Then the plug-in developer should fix this issue if they promise compatibility with Studio One. Yes, it's that easy. It's not up to the DAW developer to make sure that every single plug-in behaves correctly. There are APIs. If plug-ins conform to these APIs and the manufacturer tests them in all supported hosts, then they should work as expected.

So, not really a Studio One issue in this "Studio One complaint thread".


----------



## dcoscina (Jun 28, 2022)

GtrString said:


> Zero crashes on mac Big Sur, and Im sick of having a daw that can’t make me even consider other daw’s. What’s wrong with GAS!!?


are you on M1 Big Sur or Intel? I am not switching to Cubase- I would miss all of the macros and goodies- but I'm frustrated with the number of crashes. Now, Studio One on my MP6.1 trash can on Catalina is stable. No issues. So perhaps it's a Mac Mini thing... or M1 thing...


----------



## Lukas (Jun 28, 2022)

dcoscina said:


> are you on M1 Big Sur or Intel? I am not switching to Cubase- I would miss all of the macros and goodies- but I'm frustrated with the number of crashes.


Do you use AU versions of your plug-ins? If so, try using the VST3 version (or VST2 if there's no VST3 version).


----------



## dcoscina (Jun 28, 2022)

Lukas said:


> Do you use AU versions of your plug-ins? If so, try using the VST3 version (or VST2 if there's no VST3 version).


I don’t actually see VST2 at all I’m S1 on my Mac Mini when I’m not using Rosetta mode


----------



## FireGS (Jun 28, 2022)

Lukas said:


> If plug-ins conform to these APIs...





Lukas said:


> ...then they should work as expected


I mean, you said it. ^_^ 

In all seriousness, Ive figured out the plugin is JUCE-based, and im just wondering if the issue lies with JUCE, Studio One's handling of JUCE (or vice versa), or if its really the plugin.


----------



## FireGS (Jun 28, 2022)

Lukas said:


> So, not really a Studio One issue in this "Studio One complaint thread"


I mean, in all reality, it still *is*. It's not working in only Studio One, so it's still a complaint with Studio One. buuuuuuuuuut the jury's still out.

All the rest are super valid complaints though


----------



## rrichard63 (Jun 28, 2022)

FireGS said:


> ... other DAWs I try have no issues with Tegelers VSTs whatsoever. In fact, of all of the free DAWs and Demos of DAWs I've tried, *NONE* have the issue that Studio One does. At this point I'm very certain that with the Tegeler equipment, it's a Studio One issue.





Lukas said:


> Okay, so your plug-in does not work properly? Then the plug-in developer should fix this issue if they promise compatibility with Studio One. Yes, it's that easy. It's not up to the DAW developer to make sure that every single plug-in behaves correctly. There are APIs. If plug-ins conform to these APIs and the manufacturer tests them in all supported hosts, then they should work as expected.
> 
> So, not really a Studio One issue in this "Studio One complaint thread".


It would be nice if this could be a dialog rather than a confrontation.

@FireGS, please respond to @Lukas's point that it makes more sense for plugin developers to have to test against the available hosts (of which there might be 50 or so) than it does for host developers to have to test against the available plugins (of which there are thousands). Or, stated differently, it makes more sense for plugin developers to list the hosts they support than it does for host developers to list the plugins they support.

@Lukas, please respond to @FireGS's point that his plugin and hardware work with a variety of other hosts, just not with Studio One. What would account for that situation?


----------



## FireGS (Jun 28, 2022)

rrichard63 said:


> @FireGS, please respond to @Lukas's point that it makes more sense for plugin developers to have to test against the available hosts (of which there might be 50 or so) than it does for host developers to have to test against the available plugins (of which there are thousands). Or, stated differently, it makes more sense for plugin developers to list the hosts they support than it does for host developers to list the plugins they support.


I agree. That's why I initially reached out to the plugin devs for help. That's always the first place to go. It's just then there's the run around of everyone blaming everyone else (guilty) which isnt terrifically helpful -- its obfuscating the point, and no one is ultimately served.



rrichard63 said:


> plugin and hardware work with a variety of other hosts, just not with Studio One. What would account for that situation?



That's the point that bothers me so much. After opening the VST3 .dll file in Notepad, I could see that the plugin is built on JUCE framework. Then found a JUCE developer forum thread with someone noting a similar issue -- that automation wasn't rendering correctly in Studio One, but was working in other DAWs with the same code. So either JUCE has some faulty code in it somewhere that isn't working correctly in Studio One, or Studio One isn't correctly interpreting JUCE code. 

Or yes, there could be a plugin issue yet somewhere still. That's why I've tried to reach out to the plugin developer, Presonus, and users (since March) about this and have really gotten nowhere.


----------



## GtrString (Jun 28, 2022)

dcoscina said:


> are you on M1 Big Sur or Intel? I am not switching to Cubase- I would miss all of the macros and goodies- but I'm frustrated with the number of crashes. Now, Studio One on my MP6.1 trash can on Catalina is stable. No issues. So perhaps it's a Mac Mini thing... or M1 thing...


I'm on a 2018 Mac mini (intel)

Have you tried following a setup guide for recording? It's the first thing I always check..





Mac/PC Optimization Guides - SweetCare


Today’s computers are fast enough and powerful enough to handle most audio projects. However, there are a number of steps and settings you can make to ensure that your computer is optimally configured for audio production. Follow the instructions in these guides, and you’ll be certain that your...




www.sweetwater.com


----------



## dcoscina (Jun 28, 2022)

GtrString said:


> I'm on a 2018 Mac mini (intel)
> 
> Have you tried following a setup guide for recording? It's the first thing I always check..
> 
> ...


My intel Mac runs S1 glitch free. It's the Mac Mini M1 that seems to be having issues with the most recent build, and specifically when I'm using a lot of VSL Synchron players.


----------



## cedricm (Jun 28, 2022)

FireGS said:


> Yeah, I wish I could. I've invested a huge amount of time into S1 and a huge amount of money into Tegeler. I'm kinda stuck either way I go. The kicker is that other DAWs I try have no issues with Tegelers VSTs whatsoever. In fact, of all of the free DAWs and Demos of DAWs I've tried, *NONE* have the issue that Studio One does. At this point I'm very certain that with the Tegeler equipment, it's a Studio One issue.
> 
> The issue seems to be that the render function is disallowing network traffic. I see http requests via Wireshark when I press play heading from my machine to the Creme's IP address (it's HTTP SENDing JSON data), but when I render, theres no traffic from my machine to the Creme at all. Not even SYN/ACK data -- it's just as if the data isn't flowing from Studio One. When I shake the window, suddenly HTTP SEND data flows again. Then it stops when I let go of the window.


Something you may want to try: NUGEN Audio SigMod, presently on sale, and I think you can get a demo, is a VST host.
How about hosting this Tegeler VST into SigMod?

Also dumb question: have you tried to render the song but with no plugin window open?

Dumb question nr 2: have you configured exceptions in the Windows Firewall ?

Dumb question nr 3: have you tried to run Studio One as an Admin ?

Dumb question nr 4: Have you tried with VST2, if available?

Dumb question nr 5: Have you disabled plugin nap for this plugin?

It must be a frustrating issue, but to be fair, unless the hardware vendor sends a device for testing to Presonus, it's difficult to see how it should diagnose the issue. Unless there really is a whole class of common issues also appearing in non-hardware related plugins.


----------



## FireGS (Jun 28, 2022)

cedricm said:


> Something you may want to try: NUGEN Audio SigMod, presently on sale, and I think you can get a demo, is a VST host.
> How about hosting this Tegeler VST into SigMod?
> 
> Also dumb question: have you tried to render the song but with no plugin window open?
> ...



Trying NUGEN now.

DQ#1: Yes.
DQ#2: It's completely open. If it was firewall-based, I should have issues when hitting play in S1, but don't.
DQ#3: It's always set to 
DQ#4: Yes, is available, and same issue with both VST2 and VST3
DQ#5: I did. 

It sure is frustrating. The worst part is when I found out that shaking the "render please wait" box it springs to life. That's the worst parttttt. That shouldn't be a thing whatsoever, and its why I don't fully blame the plugin dev. People have been reporting this bug about automation and the shaking the renderbox """"fix"""" since Studio One v3.


----------



## rrichard63 (Jun 28, 2022)

In a perfect world, Presonus would send Tegeler a NFR copy of Studio One, then Tegeler would ask you lots of questions about your computer and OS, and try to replicate your problem. We don't live in a perfect world.

On a different level: DQ#6. Do you know anyone locally who has Studio One installed on a different computer and/or OS version? If so, have you tried hooking your outboard box up to that computer?

On a third level, does anybody know of another JUCE plugin whose function is to communicate with hardware over ethernet?


----------



## Wunderhorn (Jun 28, 2022)

Between the DAWS (Logic, Cubase and S1) that I have worked with my experience is that S1 performs the best out of the three. Especially in Cubase I never had a single time I could quit the program without a major crash. Especially when VEP is involved which seems to have more stability issues now than it did in the past.

Also I'd like to note that S1 has the easiest and smoothest articulation switching system so far. Cubase's half assed expression maps were a major reason why I switched to S1.
I only wanted to note that before anyone thinks about switching too quickly.
Of course, that said, everyone has their own problems and different configurations, causing different issues.


----------



## Lukas (Jun 28, 2022)

rrichard63 said:


> @Lukas, please respond to @FireGS's point that his plugin and hardware work with a variety of other hosts, just not with Studio One. What would account for that situation?


Yes: It's a common misconception that if a plug-in works properly in one host but not in another, then it is the host's fault. A wrong API call from the plug-in might fail in one software but pass in another host - because it's a different software with different implementations.

It's also an open secret that Cubase or Logic try to fix problems in plug-ins... to also catch bugs or faulty VST (/ AU) implementations in 2002 freeware synths. Software that should not run at all then somehow works anyway.

It's also an open secret that Studio One does not try to fix bugs within plug-ins (there are some exceptions but that's the tendency).

And when we're talking about AU plug-ins: There are plug-in developers that don't test their AU versions in other hosts than Logic - or at least not in Studio One. We are back to the beginning: If the manufacturers do not test a plug-in in one host, then there can be issues in this host. But that's the reason why I usually recommend not to use AU plug-ins in Studio One.



FireGS said:


> So either JUCE has some faulty code in it somewhere that isn't working correctly in Studio One, or Studio One isn't correctly interpreting JUCE code.


I can't say anything general about JUCE & Studio One: But Studio One does not interpretes their code. A plug-in is an own piece of software but running within the same process (if no sandboxing involved). If the plug-in sends bad requests to the host, the results may be unpredictable. If the plug-in crashes, the host crashes as well.

So that's why I said: If the plug-in doesn't work properly in one single host, than this means that.... it doesn't work properly in that host  But it should work in all supported hosts.


----------



## FireGS (Jun 28, 2022)

rrichard63 said:


> In a perfect world, Presonus would send Tegeler a NFR copy of Studio One, then Tegeler would ask you lots of questions about your computer and OS, and try to replicate your problem. We don't live in a perfect world.
> 
> On a different level: DQ#6. Do you know anyone locally who has Studio One installed on a different computer and/or OS version? If so, have you tried hooking your outboard box up to that computer?
> 
> On a third level, does anybody know of another JUCE plugin whose function is to communicate with hardware over ethernet?



Not a dumb question #6: I just installed and tried it on my laptop, Win 11, S1 5.5.2, exact same behavior.


----------



## Lukas (Jun 28, 2022)

rrichard63 said:


> In a perfect world, Presonus would send Tegeler a NFR copy of Studio One, then Tegeler would ask you lots of questions about your computer and OS, and try to replicate your problem. We don't live in a perfect world.


That's indeed what happens in many cases - so there are good chances to get this right.


----------



## FireGS (Jun 28, 2022)

Lukas said:


> A plug-in is an own piece of software but running within the same process (if no sandboxing involved). If the plug-in sends bad requests to the host, the results may be unpredictable.





Lukas said:


> A wrong API call from the plug-in might fail in one software but pass in another host - because it's a different software with different implementations.





Lukas said:


> I can't say anything general about JUCE & Studio One: But Studio One does not interpretes their code.



OK, so. I'm trying to understand this.. If Studio One does no interpreting of the code, and the code works globally -- why would such an API call that works everywhere else fail to work on S1? I'm honestly asking, because this doesn't make sense to me -- unless Studio One is interpreting code in a different way.


----------



## rrichard63 (Jun 28, 2022)

FireGS said:


> ... i'm just wondering if the issue lies with JUCE, Studio One's handling of JUCE (or vice versa), or if its really the plugin.


DQ#7 (with apologies if this has already been covered): do you have any other plugins, preferably ones not built with the JUCE framework, that communicate with some device (any device) over ethernet? If so, do they behave differently in Studio One than they do in other VST hosts?


----------



## Lukas (Jun 28, 2022)

@FireGS: I can't give you a general answer but as an example: Maybe Studio One supports a certain VST feature that Ableton Live does not support. But the plug-in makes use of that feature - but has some bugs. Plug-in running in Live asks if the host supports functionality X - it does not. So plug-in doesn't run the code for this functionality. Now Studio One responds that functionality X is supported so the plug-in runs this code... and because something's not compatible, it behaves wrong - or even crashes. Now the plug-in might run in Sonar and Sonar also supports feature X but does not crash - why? Because it doesn't support another feature Y that Live does support... so the plug-in behaves differently as a consequence.

Not very great explained and rather constructed story, I'm tired and it's late, I'm sorry. But at least maybe it makes it clear that the devil is usually in the (technical) detail... when issues occur, you always have to debug and go into detail.


----------



## FireGS (Jun 28, 2022)

Lukas said:


> @FireGS: I can't give you a general answer but as an example: Maybe Studio One supports a certain VST feature that Ableton Live does not support. But the plug-in makes use of that feature - but has some bugs. Plug-in running in Live asks if the host supports functionality X - it does not. So plug-in doesn't run the code for this functionality. Now Studio One responds that functionality X is supported so the plug-in runs this code... and because something's not compatible, it behaves wrong - or even crashes. Now the plug-in might run in Sonar and Sonar also supports feature X but does not crash - why? Because it doesn't support another feature Y that Live does support... so the plug-in behaves differently as a consequence.
> 
> Not very great explained and rather constructed story, I'm tired and it's late, I'm sorry. But at least maybe it makes it clear that the devil is usually in the (technical) detail... when issues occur, you always have to debug and go into detail.



Its late here too, I hear you. But...................... 

The explanation sounds like a bunch of DAWs supporting or not supporting things. I'd say thats the DAWs interpreting the same base code of the plugins differently.


----------



## Lukas (Jun 28, 2022)

FireGS said:


> The explanation sounds like a bunch of DAWs supporting or not supporting things. I'd say thats the DAWs interpreting the same base code of the plugins differently.


Thanks for reporting back that my attempt at explanation was completely off :D 🍻


----------



## Marcus Millfield (Jun 28, 2022)

dcoscina said:


> I’ve had a lot of crashes since the last update on Mac OS M1, mostly with VSL Synchron player…


Me too, but on Windows. Had a case going at Presonus for that, but in the end they pointed to VSL. The issue pops up a lot when saving custom patches in Synchron Player. No issues with VIPro so far.

Just wished VSL would make sound variation templates for VIPro too, just a few stock matrices would do as a starting point.


----------



## CatComposer (Jun 28, 2022)

As a Windows 10 user, I have learned the hard way that the most common reason plugins don't work well in Studio one is corrupted Windows files.
And I suspect this occurs during the uninstallation of certain plugins and programs which share common files with the plugins you want to use.

For example, I was testing out many free plugins (eg. analog obsession), and after uninstalling them, started to get popping sounds in Noire Piano.
Only after a fresh install of Windows 10 was I able to get Noire Piano working normally.

Also I have stopped installing Waves plugins due to their extensive installation tentacles which seem to show up in many unexpected places.

I find that if I keep my plugins to a minimum, Studio One works perfectly and never crashes.

I have also looked into the JUCE framework and that is truly a can of worms!
I suspect that any line of thousands of lines of code could be the cause of your problems.
JUCE is basically a compatibility wrapper that makes a VST compatible with every DAW and platform.
So most of the code will be irrelevant, and perhaps unhelpful.

If a Windows 10 reinstallation doesn't solve your issues, I suspect you'll probably have to dig into the log files and consult with a very knowledgeable person (eg. someone who programs in JUCE).

As far as Studio One goes, it's so much more intuitive and has so many great features that Cubase doesn't have, that I will never go back to Cubase.
Getting my hardware controller to work in Virtual Instruments does take a bit of fiddling, but I can always get it working if I click in the right places!
It's all about knowing where to click! 😊

Hopefully Studio One will make that process smoother in the future, and also add the other features you mentioned, but I wouldn't expect this to happen next week.
Personally, I feel that the advantages Studio One gives in terms of workflow and ease of use blow away the competition (except for Logic, but I will never buy a Mac 😉 ).


----------



## Marcus Millfield (Jun 28, 2022)

CatComposer said:


> As a Windows 10 user, I have learned the hard way that the most common reason plugins don't work well in Studio one is corrupted Windows files.
> And I suspect this occurs during the uninstallation of certain plugins and programs which share common files with the plugins you want to use.


That's all well and good, but why don't my other DAWs or plugins have these issues on the same machine? What makes S1 so different that it's the only VST host that keeps crashing when I load certain plug-ins?

Before you answer: I appreciate your response, it's no personal attack and these are rethorical questions


----------



## pinki (Jun 28, 2022)

CatComposer said:


> It's all about knowing where to click! 😊
> 
> Hopefully Studio One will make that process smoother in the future, …………. (except for Logic, but I will never buy a Mac 😉 ).


Ain‘t this the truth…
I find the collection of arcane symbols in S1 so frustrating…Presonus need a masterclass on this from Apple.


----------



## CatComposer (Jun 28, 2022)

Marcus Millfield said:


> That's all well and good, but why don't my other DAWs or plugins have these issues on the same machine? What makes S1 so different that it's the only VST host that keeps crashing when I load certain plug-ins?
> 
> Before you answer: I appreciate your response, it's no personal attack and these are rethorical questions


My working theory is that Studio One is based on much newer code than an older DAW like Cubase.
This makes it more efficient and snappy, but less compatible with plugins developed in the computer stone ages (eg. prior to 2015). 🤣

My experience is that Studio One is stable as a rock, as long as you avoid old plugins.


----------



## muziksculp (Jun 28, 2022)

I agree. S1Pro 5 has been solid for me, no issues what so ever.


----------



## Marcus Millfield (Jun 29, 2022)

CatComposer said:


> My experience is that Studio One is stable as a rock, as long as you avoid old plugins.


Not my experience, with new plug-ins.


----------



## muziksculp (Jun 29, 2022)

Marcus Millfield said:


> Not my experience, with new plug-ins.


Any thing specific you can mention here ?


----------



## ThomasL (Jun 29, 2022)

Slim chance but any change if you add the automated parameter on the macro knobs and automate those instead?


----------



## Marcus Millfield (Jun 29, 2022)

muziksculp said:


> Any thing specific you can mention here ?


Editing patches in Synchron Player keeps crashing S1. Did a support call, but off course they point to VSL. No issues in other VST hosts with this plugin. As almost all my orchestral libs are VSL, this is highly inconvenient.


----------



## Scripter (Jun 29, 2022)

FireGS said:


> Not sure if one of these already exists, but I'm somewhat at my wits end with some super basic functionality either broken, or non-existent inside Studio One. I've made support tickets, threads on the Presonus forum, contacted 3rd parties to poke Presonus about these issues and just getting nowhere after months and months -- so now I'm going to bitch about it here.
> 
> Serious issue: Studio One doesn't handle plugins (VST) either well, or properly, or both (Win 10). I have a Tegeler Creme RC that is a hardware compressor/EQ that's digitally controlled by a VST over ethernet. All of the knobs can be automated by track automation. I have some output knob automation programmed. It responds during playback, but rendering in real time with Studio One, the knob just stays at the last value it was at, never resets, doesn't change over time as programmed either. Weirdly enough, if you shake the "rendering" window while its rendering, the knobs suddenly come to life. If I release the window, the automation stops again.
> 
> ...



No issues with Effekt VST's or VST3 Plugins here, really. Also S1 is running pretty stable on my Windows 10 System for a few years now. Yes sometimes it crashes but not more often than other DAW (hadn't experienced any crashed the last months. 

However I agree with Issue #5: Thats damn stupid. Also Kontakt and other VST Instrument Plugins missbehave when cached files setting is turned on. It just deletes the Pluginstates entirely when reopening the project. Opened a support ticked nobody couldn't help. However turning of this setting solves the issues for me.


----------



## GtrString (Jun 29, 2022)

CatComposer said:


> A major source of software instability is malware, which is surprisingly ubiquitous and cleverly hides in Windows system files.
> I have found that using Brave browser and Kaspersky (which is far more sensitive than Windows defender) are the best ways to protect my system and keep Studio One stable.
> 
> If you're getting crashes in Studio One, it's worth trying a clean re-install of Windows 10, and installing Kaspersky before doing any web browsing.


I don't think you'd want to use Kaspersky to be more secure 









Is it safe to use Russian-based Kaspersky antivirus? No, and here's why


If you use Kaspersky antivirus software, you might be a victim of cyber warfare. Here's why you must remove it immediately.




www.komando.com


----------



## Lukas (Jun 29, 2022)

Marcus Millfield said:


> Editing patches in Synchron Player keeps crashing S1. Did a support call, but off course they point to VSL.


Yes, of course, a host can't prevent a plug-in from crashing. You should have contacted VSL. VSL and PreSonus have a very good connection so if there are issues (that can be reproduced), chances are very good to sort them out. Did you report it to VSL's support?


----------



## Marcus Millfield (Jun 29, 2022)

Lukas said:


> Yes, of course, a host can't prevent a plug-in from crashing. You should have contacted VSL. VSL and PreSonus have a very good connection so if there are issues (that can be reproduced), chances are very good to sort them out. Did you report it to VSL's support?


In the proces of doing so yes.


----------



## John Judd (Jun 29, 2022)

Regarding crashes: in 2 years of Studio One, I have had exactly 2 crashes total. Very stable over here, on W10. 

I DO have an issue with track dropouts. Currently just living with it, but I’ve never seen that behavior in my other DAWS.


----------



## Cheezus (Jun 29, 2022)

CatComposer said:


> A major source of software instability is malware, which is surprisingly ubiquitous and cleverly hides in Windows system files.
> I have found that using Brave browser and Kaspersky (which is far more sensitive than Windows defender) are the best ways to protect my system and keep Studio One stable.
> 
> If you're getting crashes in Studio One, it's worth trying a clean re-install of Windows 10, and installing Kaspersky before doing any web browsing.


My friend used Kaspersky until very recently and when he had to contact Presonus for technical support they told him to disable it.

Kaspersky probably makes things worse not better.


----------



## Zedcars (Jun 29, 2022)

FireGS said:


> The issue seems to be that the render function is disallowing network traffic. I see http requests via Wireshark when I press play heading from my machine to the Creme's IP address (it's HTTP SENDing JSON data), but when I render, theres no traffic from my machine to the Creme at all. Not even SYN/ACK data -- it's just as if the data isn't flowing from Studio One. When I shake the window, suddenly HTTP SEND data flows again. Then it stops when I let go of the window.



A temporary workaround might be to use Autohotkey to shake the window when you need it shaken (but not stirred!).

It should be relatively straight-forward to program the necessary mouse moves.

I have no idea what is going on here on a technical level. Perhaps the mouse interacting with the window triggers another process which somehow opens the network data or removes the block on it? No idea.


----------



## SonicMojo (Jun 29, 2022)

Marcus Millfield said:


> Why don't my other DAWs or plugins have these issues on the same machine? What makes S1 so different that it's the only VST host that keeps crashing when I load certain plug-ins?


In my long experience with many a DAW - I would echo what a few others have said about how other "older" DAWS (like Cubase for example) have so much baggage and were written so long ago that they most likely have code workarounds (or other detours) that somehow allow them to navigate these oddball plugins to give the appearance of "working".

But that is not necessarily 100% true. Lukas mentioned this earlier that S1 is one of the few DAWS (or perhaps the only one) - that is very strict in it's adherence to spec and yes - unfortunately - when a plugin might be trying some funny crap IN THEIR CODE - S1 might simply ignore it, freeze or even crash because of it.

Things are not fair in the plugin DEV world - even today - it is still the wild west where some devs continually push the boundaries of the VST spec with little care about how a given DAW might react where other vendors respect the rules and this usually results in smooth sailing.

And for most of us - we already know who the real players are and who is trying to bend the rules.

If S1's code base is as solid as I believe it is and totally respects the rules of the VST APIs - even if that means crashing and burning - I would respect that well before allowing some suspect plugin to ruin my day.

And - can anyone 100% confirm that this Tegeler Creme RC plugin is actually supported in Studio One - or are there some assumptions being made there as well?

Sonic.


----------



## Marcus Millfield (Jun 29, 2022)

As a user I don't give a crap about perfect codebases and adherence to dev standards, as long as the product works and I can make music with it the way I want to. If that means I need to use a product that implemented 100 workarounds, so be it. At least those work...

Calling VSL Synchron Player the oddball VST 😂

But yeah, I get it, not gonna win this one 👍🏻


----------



## SonicMojo (Jun 29, 2022)

Marcus Millfield said:


> As a user I don't give a crap about perfect codebases and adherence to dev standards, as long as the product works and I can make music with it the way I want to. If that means I need to use a product that implemented 100 workarounds, so be it At least those work...
> 
> But yeah, I get it, not gonna win this one 👍🏻


Trust me - I spend zero time thinking about codebases - and just want my stuff to work so I can get on with it - but I do take the usual (normal?) steps to make sure any plugin I am even thinking of buying is *100% supported, tested and are known to be working properly in my main DAW* - before:

A) I buy it (no trial - no sale here)
B) Before I swing onto a forum like this and trash out my DAW - blaming it for all the issues.

I never take chances (on any software) especially if my own money is involved. As far as Studio One goes - as good as it is - I never blindly buy any plugin with the assumption that just because it's a "VST" plugin - its going to automatically work in S1. 

That is wishful thinking that could get real expensive real fast and leave me with a pile of crap I can't use.

Sonic.


----------



## clonewar (Jun 29, 2022)

For everyone saying that the plug-in issue @FireGS is reporting is not an S1 issue, go back and watch the video that he initially posted. The plugin works fine until an Export Mixdown operation, where it stops sending automation data unless the S1 Render Progress window is moved around, which magically prompts S1 to send the automation data to the plug-in. That has to be an S1 issue.

My personal experience with S1 on Windows is mostly positive. The only crashes I’ve had since building my new Ryzen 5950X PC last year have been when Synchron player is in the project. I still mix in PT, and Ive moved to a notation workflow for composing and orchestrating in Staffpad and Dorico, but for sketching, general playing, and final MIDI editing I love S1’s fast workflow and intuitive UI.


----------



## Lukas (Jun 29, 2022)

SonicMojo said:


> Things are not fair in the plugin DEV world - even today - it is still the wild west where some devs continually push the boundaries of the VST spec with little care about how a given DAW might react where other vendors respect the rules and this usually results in smooth sailing.


Agreed 100%.



SonicMojo said:


> If S1's code base is as solid as I believe it is and totally respects the rules of the VST APIs - even if that means crashing and burning - I would respect that well before allowing some suspect plugin to ruin my day.


Matthias Juwan, the father and inventor of Studio One, wrote the VST3 specification back then. He knows the rules.



clonewar said:


> For everyone saying that the plug-in issue @FireGS is reporting is not an S1 issue, go back and watch the video that he initially posted. The plugin works fine until an Export Mixdown operation, where it stops sending automation data unless the S1 Render Progress window is moved around, which magically prompts S1 to send the automation data to the plug-in. *That has to be an S1 issue.*


No. Why? What I see is that the plug-in does not respond to Host Automation during real-time mixdown. What I don't see is any reasoning in your text why this should indicate that Studio One is causing this problem. To know that Studio One is behaving incorrectly, you would need to debug the code of the plug-in. I don't think you did that (only the plug-in manufacturer can do that).

But in the end, that's not the question. If a plug-in manufacturer wants its plug-ins to run properly in Studio One, then they need to test them in this environment. That's how software development works.


----------



## SonicMojo (Jun 29, 2022)

clonewar said:


> For everyone saying that the plug-in issue is reporting is not an S1 issue, go back and watch the video that he initially posted. The plugin works fine until an Export Mixdown operation, where it stops sending automation data unless the S1 Render Progress window is moved around, which magically prompts S1 to send the automation data to the plug-in. That has to be an S1 issue.


I do not recall saying that this is NOT an S1 issue - it may very well be one and S1 may also have a half dozen clearcut reasons why it does not like this specific plugin. But that does not necessarily make it a problem OR issue.

This plugin may not be hooking the API (as S1 offers it) correctly. S1 may not like what it gets (or does not get) from the Creme plugin code (Most likely here). The plugin may be trying some weird crap (in it's code) that Cubase (for example) has an old code workaround for - so it seems to work there.

The point is - Studio One is modern, handles well written VST plugins very well and is battle tested by thousands of users worldwide in real world situations. This is not some new kid that has trouble with plugins.

But hey - back to the key question - can anyone out there tell us if this plugin was actually tested and/or listed as FULLY supported by Studio One? If the vendor (DEV) cannot confirm this or there is no documentation to support this most basic of requirements - then we are going around in circles here.

SOnic.


----------



## Lukas (Jun 29, 2022)

Here's the installer of this plug-in:






Seriously?

Seeing this, I have no further questions regarding this software.


----------



## cedricm (Jun 29, 2022)

If the plugin is freely available and works without the hardware I could test it on my system.

Downloaded and installed in the correct folder.

But it complains about not finding the device when starting the plugin, so I won't be able to test further.


----------



## FireGS (Jun 29, 2022)

Lukas said:


> No. Why? What I see is that the plug-in does not respond to Host Automation during real-time mixdown. What I don't see is any reasoning in your text why this should indicate that Studio One is causing this problem. To know that Studio One is behaving incorrectly, you would need to debug the code of the plug-in. I don't think you did that (only the plug-in manufacturer can do that).


Because man, you can't tell me that shaking the render window should affect anything either positively or negatively. What is S1 doing that shaking the render window has *any efffect whatsoever on a plugin*?


----------



## Lukas (Jun 29, 2022)

Updating the UI? I don't know. I don't like guessing around. Why don't you ask the plug-in manufacturer? Again: If they want that their plug-ins run properly in your host, then they have to test it in this environment. (And tell them to improve their installer, too.)


----------



## FireGS (Jun 29, 2022)

Lukas said:


> Updating the UI? I don't know.



OK then, that's the point. Studio One shouldn't be hindering anything during a render. No other DAW seems to. 

Weirdly enough, even when theres no UI visible, the issue still happens, and the workaround of shaking the UI still works. 



Lukas said:


> Why don't you ask the plug-in manufacturer?


I have, I'm waiting to hear back.


----------



## clonewar (Jun 29, 2022)

Lukas said:


> No. Why? What I see is that the plug-in does not respond to Host Automation during real-time mixdown. What I don't see is any reasoning in your text why this should indicate that Studio One is causing this problem. To know that Studio One is behaving incorrectly, you would need to debug the code of the plug-in. I don't think you did that (only the plug-in manufacturer can do that).
> 
> But in the end, that's not the question. If a plug-in manufacturer wants its plug-ins to run properly in Studio One, then they need to test them in this environment. That's how software development works.


Because, like @FireGS said above, moving S1’s export progress window triggers S1 to send automation data to the plug-in during the export. The plug-in would have no control over or exposure to S1’s export progress window.

Maybe S1 changes how it’s sending automation data during an export that the plug-in isn’t dealing with? But then again if that was the case why would moving the export window trigger S1 to send automation data? The fact that S1 starts sending automation data when moving the window points to a bug in S1.


----------



## SonicMojo (Jun 29, 2022)

Lukas said:


> Here's the installer of this plug-in:
> 
> 
> 
> ...


That is enough for me as well.

SOnic


----------



## Lukas (Jun 29, 2022)

clonewar said:


> moving S1’s export progress window triggers S1 to send automation data to the plug-in during the export. The plug-in would have no control over or exposure to S1’s export progress window.





clonewar said:


> The fact that S1 starts sending automation data when moving the window points to a bug in S1.


It is remarkable that you speak of things you do not know (and wildly guess) as a fact.

You can do that.

Others write software.



FireGS said:


> I have, I'm waiting to hear back.


Ok great. Please report back when you have an answer.


----------



## FireGS (Jun 29, 2022)

Lukas said:


> It is remarkable that you speak of things you do not know (and wildly guess) as a fact.
> 
> You can do that.
> 
> Others write software.


Quick aside -- it seems like you're taking any criticism of Studio One really personally, like we're attacking you directly for some reason. I don't understand this behavior? Are you officially a Presonus representative now?


----------



## Lukas (Jun 29, 2022)

FireGS said:


> Quick aside -- it seems like you're taking any criticism of Studio One really personally, like we're attacking you directly for some reason.


No, not at all. I often criticize Studio One myself (to make it better). It's just a mystery to me why people make claims about what happens inside a piece of software when they don't know it. It may be entertaining... but doesn't help anyone.



FireGS said:


> Are you officially a Presonus representative now?


No. Just a good friend of theirs. However, I was often involved in feature design, development and content creation so I know big parts of the program quite well. But a representative? No, I wouldn't say that.


----------



## FireGS (Jun 29, 2022)

@Lukas What are your thoughts on this thread: https://forums.presonus.com/viewtopic.php?f=151&t=44763

Seems like its a repeatable issue without the Tegeler plugins. There are multiple people in there claiming that to fix a stuck plugin, you can shake the windows. People even made macros with third party apps to shake the window for them. If it was just me, and just this plugin, I could more easily write it off as the plugin is at fault -- but it's not just me and its not just this plugin. 

As one user wrote: 



> There's definitely some kind of race condition that happens during Offline render, which is why shaking the box "unlocks" the stuck thread responsible for reading and applying the automation. It's not surprising that in some cases, this would instead cause the audio rendering to cut out.


----------



## babylonwaves (Jun 29, 2022)

Lukas said:


> Officially? No. Just a good friend who knows the program very well and is only sometimes involved in development. But a representative? No.


"Studio One Software Specialist" sounds pretty official


----------



## jbuhler (Jun 29, 2022)

I used S1 for many years. For most of that time S1 always crashed on quit. Presonus never could figure out why. I concluded it had something to do with Kontakt. For much of that time S1 had other issues with Kontakt.

Lukas can say it’s the defective plugin’s responsibility all he wants and maybe it is the plug-in’s fault but if the plugin developer refuses to address the issue and Presonus refuses to address the issue and if no other DAW has this issue, am I going to drop Kontakt or S1 to address the issue? I never upgraded to V5 and am not currently using S1.


----------



## Lukas (Jun 29, 2022)

FireGS said:


> What are your thoughts on this thread: https://forums.presonus.com/viewtopic.php?f=151&t=44763


First thought is that some of the posts don't mention which plug-ins are used. That would be pretty important to know first. Then there seem to be different scenarios in this thread (different plug-ins, real-time mixdown / offline mixdown).

You wrote:


> Sure is. I had a Zoom call with the devs at Tegeler and showed them this ridiculousness, said they were going to contact Presonus directly and get some answers. I've also reopened my ticket with Presonus.


If they're in connection with PSL already, that's great. You didn't mention that.



babylonwaves said:


> "Studio One Software Specialist" sounds pretty official


Well, it's the term they use - why not? Does it make me a representative? I don't know. Is this official? Is this important? 



jbuhler said:


> Lukas can say it’s the defective plugin’s responsibility all he wants and maybe it is the plug-in’s fault but if the plugin developer refuses to address the issue and Presonus refuses to address the issue and if no other DAW has this issue, am I going to drop Kontakt or S1 to address the issue? I never upgraded to V5 and am not currently using S1.


Annoying, of course. But you won't find a DAW developer that will stop its further development to spend its time only fixing bugs in faulty plug-ins.


----------



## jbuhler (Jun 29, 2022)

Lukas said:


> Annoying, of course. But you won't find a DAW developer that will stop its development to spend its time only fixing bugs in faulty plug-ins.


Within reason, I would say. If a DAW is having issues with something like Kontakt, I would imagine (in fact in my experience this is the case) the DAW developer is very interested in getting to the bottom of the issue. Presonus in my experience is the only DAW developer I've experienced that essentially says "well, that's too bad for you." It wasn't helped by the fact that Presonus support had become very unresponsive by the time I departed S1. I mean, Native Instrument's support is also mostly unresponsive at this point, meaning that if you have an issue between S1 and a NI plugin, the hope of getting it resolved is about nil. Apple by contrast has always been very helpful at getting to source of these sorts of issues, and it is one of the reasons I have mostly abandoned S1 at this point.


----------



## babylonwaves (Jun 29, 2022)

Lukas said:


> Does it make me a representative? I don't know. Is this official? Is this important?


It's probably not important. Still, people using a title like this oftentimes serve an official role for a company. And that's the potentially confusing part for others. You can keep your title, I don't care. Whatever floats your boat dude  - Maybe it would be a good idea for Presonus to have an official representative posting here.


----------



## Lukas (Jun 29, 2022)

I sometimes do that - as you know. I was at the PreSonus booth at Superbooth/Musikmesse/IMSTA FESTA a number of times. I made videos and content for Studio One, I also developed parts of the MIDI functionality and some other features. Apart from that, I am a musician. In the music industry, things are usually a little more open. I don't think so much about titles  I think there are more important things.
I'm here to talk about music software. And if I can help with Studio One questions, I'm happy to do so.


----------



## babylonwaves (Jun 29, 2022)

So you're a freelancer for Presonus. Fine. Let's move on. Here are people who're having compatibility issues. With your connection, It might be an idea to bring those to the attention of the right parties.


----------



## Lukas (Jun 29, 2022)

babylonwaves said:


> With your connection, It might be an idea to bring those to the attention of the right parties.





FireGS said:


> I have, I'm waiting to hear back.





> I had a Zoom call with the devs at Tegeler and showed them this ridiculousness, said they were going to contact Presonus directly and get some answers.


----------



## clonewar (Jun 29, 2022)

Lukas said:


> It is remarkable that you speak of things you do not know (and wildly guess) as a fact.
> 
> You can do that.
> 
> Others write software.


I don't think it's a wild guess, anyone who watches the video that @FireGS posted with an open mind can clearly see that the flow of automation to the plug-in gets 'un-stuck' by moving an S1 window. How could that be the fault of the plug-in?

FYI, I write software for a living. Full time. Music is my second job.


----------



## DaddyO (Jun 29, 2022)

It is curious to me how often people who write software for a living get into sharp disputes with people on forums associated in some way with that forum's software..

(I don't write software for a living.)

Maybe I'm wrong here, but it seems to this observing outsider that writing software for some completely different application doesn't necessarily qualify one to make specific judgments about something in a software that may have complications and parameters wholly foreign to the general software writer.

Now the critic may be qualified to do so, indeed may be eminently qualified, but I would think there would be a degree of humility in such situations unless eminently qualified in that particular application. And to me that would mean very familiar with the ins and outs of the particular type of software under discussion. After all, I would assume that the software-writing person has had the tables turned on him many times, and someone only partly qualified made errant assumptions about his software.

'Course, this a forum, and it's for people to share their thoughts and opinions, positive, contrary, lauditory or critical. So I'm not objecting to any posts. I'm just an observer who has his own opinion to share.

Also of course, a frustrated user is entitled to express the way they look at things.


----------



## clonewar (Jun 29, 2022)

DaddyO said:


> It is curious to me how often people who write software for a living get into sharp disputes with people on forums associated in some way with that forum's software..
> 
> (I don't write software for a living.)
> 
> ...


The only reason I mentioned that I'm a developer is because Lukas said "Others write software" as an insult to me. I didn't say that I have knowledge of S1's code or inner workings, but obviously that's not necessary to offer an armchair opinion on a forum, which is what I'm doing. Once again, the video that @FireGS initially posted demonstrates that automation data isn't being passed to the plug-in during an export operation, but the data starts flowing while S1's export window is being moved. From a debugging perspective I can tell you that you'd start with determining what's changing when the window is being moved and work from there.

Also, like @FireGS said, this has been a long-reported issue with S1 exports: https://forums.presonus.com/viewtopic.php?f=151&t=44763


----------



## Lukas (Jun 29, 2022)

clonewar said:


> The only reason I mentioned that I'm a developer is because Lukas said "Others write software" as an insult to me.


Not at all! Just pointing out that looking at the UI (in the video) and making guesses without knowing what's going on is pretty much the opposite of debugging a piece of software which means to find out what exactly happens inside the code in a certain situation.



clonewar said:


> Once again, the video that @FireGS initially posted demonstrates that automation data isn't being passed to the plug-in during an export operation


Again: No. We don't know that. It's possible... but it's also possible that the plug-in just does not process the automation. We see the result (knobs not moving and the hardware not changing parameters), but not what causes it and why.


----------



## estolad (Jul 1, 2022)

clonewar said:


> I don't think it's a wild guess, anyone who watches the video that @FireGS posted with an open mind can clearly see that the flow of automation to the plug-in gets 'un-stuck' by moving an S1 window. How could that be the fault of the plug-in?
> 
> FYI, I write software for a living. Full time. Music is my second job.


Lots of things go wrong in software development, you should know that. You never know how some code is written if you don't have access. There's plenty of WTF code (visit https://thedailywtf.com/ for examples).

One could write code that has a dependency on some GUI component that might not be updated in some hosts until something is moved on the screen. This is probably not a smart thing to do, but it could happen.

Besides that, the JUCE framework is used by a lot of plugins. I think most of us are using or have used some plugins based on this framework. So it could also be that Tegeler is using some obscure part of the framework, only part of it plus their own custom code, or an outdated version where this issue has long been fixed in a newer version of the framework. So it being JUCE doesn't mean a lot really.

Another famous DAW that has a lot of issues with VST plugins is FL Studio. In the VST (at least version 2) spec it didn't specify that buffer sizes needed to be of fixed length. FL Studio might be the only host where this isn't fixed by default and a lot of VST plugins crash because of this. Is the fault then with the DAW, the plugin or the spec? FL Studio has the option to force fixed buffer sizes, but this is really an issue with the plugin developers that are not adhering to the VST spec.


----------



## clonewar (Jul 2, 2022)

Lukas said:


> Not at all! Just pointing out that looking at the UI (in the video) and making guesses without knowing what's going on is pretty much the opposite of debugging a piece of software which means to find out what exactly happens inside the code in a certain situation.


Of course, it takes access to the source and a good understanding of it to actually attempt to actually debug the issue. On a forum like this it's more of an 'armchair quarterback' observation scenario.



Lukas said:


> Again: No. We don't know that. It's possible... but it's also possible that the plug-in just does not process the automation. We see the result (knobs not moving and the hardware not changing parameters), but not what causes it and why.


Very true, it could be that the plugin has stopped responding to automation data in that scenario. But, the issue of automation being ignored during export has been long reported in S1, with different plugins and on different systems, and shaking/moving S1's export progress window is a known workaround to get automation data flowing. 

Could it be that there are a lot of plugins out there that have the same bug that causes them to ignore automation data only during an export process and only in S1, and that moving S1's export progress window causes them to process the data? Sure, anything is possible. But IMO it's more likely that the issue resides in S1. 

If the Tegeler devs are able to reproduce the issue then I'd think it would be easy enough to determine whether S1 has stopped sending automation data, or if it's their plugin that has stopped responding to the data. It sounds like they've reached out to Presonus about the issue, so hopefully the root cause will be found and resolved.


----------



## Lukas (Jul 2, 2022)

clonewar said:


> If the Tegeler devs are able to reproduce the issue then I'd think it would be easy enough to determine whether S1 has stopped sending automation data, or if it's their plugin that has stopped responding to the data. It sounds like they've reached out to Presonus about the issue, so hopefully the root cause will be found and resolved.


Agreed.


----------



## clonewar (Jul 2, 2022)

estolad said:


> Lots of things go wrong in software development, you should know that. You never know how some code is written if you don't have access. There's plenty of WTF code (visit https://thedailywtf.com/ for examples).
> 
> One could write code that has a dependency on some GUI component that might not be updated in some hosts until something is moved on the screen. This is probably not a smart thing to do, but it could happen.
> 
> ...


I don't disagree with your points. But, like I said above, this has been a long-reported issue with the S1 export process and different plugins. I think, given what's been reported, that it's more likely an issue in S1, but to your point maybe all of those plugin devs are using a library that's causing the issue. I'm just hoping that Presonus and the Tegeler devs are able to get to the bottom of this.


----------

