Hi guys. I am a fellow SB user and I recently started offering my plugins on a larger scale. I personally use these plugins on a daily basis and I love them (Thanks SB). However I have run into some issues with sharing the plugins. Some people can use them some can't. I am looking to see if any of you have had sharing issues and could offer some insight to how you corrected the problem. I have attempted to get in contact with the creator of SB but I'm sure that he has a lot going on ( I hope with SB 2.0).
Let me know if you have any suggestions.
Thanks
Q&A regarding SB and Commercial Distribution
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
Last edited by windwalker on Sun Jul 27, 2008 10:58 pm, edited 4 times in total.
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
Anyone out there?
-
- KVRist
- 277 posts since 3 Apr, 2007
Hi windwalker,
I did reply via PM, and I can look into it further but -
As a common solution:
Have you verified the SB version you used to export your plugin is the version of the framework your users have installed? Framework version mismatches have caused problems. Re-exporting has helped some people. (This I am aware of). Have you tried re-exporting, supporting only 1 binary version (whichever works best for your plug)? And do the problems still exist in this case?
If there is a specific version of the SB framework that works best with your plugin, use that - and do send in incompatibility reports if you encounter them, they will be read. Though, there is not much we can do for existing releases.
J
I did reply via PM, and I can look into it further but -
As a common solution:
Have you verified the SB version you used to export your plugin is the version of the framework your users have installed? Framework version mismatches have caused problems. Re-exporting has helped some people. (This I am aware of). Have you tried re-exporting, supporting only 1 binary version (whichever works best for your plug)? And do the problems still exist in this case?
If there is a specific version of the SB framework that works best with your plugin, use that - and do send in incompatibility reports if you encounter them, they will be read. Though, there is not much we can do for existing releases.
J
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
Thanks Eigentone! I have also read your pm as well and appreciate all of your help. I am working on the solution now and I will update you as soon as I finish.
Thanks again!
Thanks again!
-
- KVRist
- 92 posts since 29 Nov, 2007
The plugs certainly LOOK cool 
Actually, I would love to try them and will grab the demos later today.
Just a question: I may have missed it in the literature on the site but these plugs require that the user has SB framework installed on their system. I didn't see that anywhere on the site. Or did you create installers so that it's done for them when the plugs are installed?
The reason I ask is because you seem to have done what I was thinking of doing for some time - that is, create plugs and sell them. But I was wary of having to rely on the SB framework on the users end. So I've started to code native AU in Xcode and used SB as an experimental toolbox to create the first versions of the plugs before going to code.
Actually, I would love to try them and will grab the demos later today. Just a question: I may have missed it in the literature on the site but these plugs require that the user has SB framework installed on their system. I didn't see that anywhere on the site. Or did you create installers so that it's done for them when the plugs are installed?
The reason I ask is because you seem to have done what I was thinking of doing for some time - that is, create plugs and sell them. But I was wary of having to rely on the SB framework on the users end. So I've started to code native AU in Xcode and used SB as an experimental toolbox to create the first versions of the plugs before going to code.
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
Thanks for the GUI compliment. Yes, I created an installer with the framework included. So far I have had good to mixed results. Also as you may know it is possible that conflicts can occur if there are existing plugins that require a different version of the framework. I plan on adding the "created with SonicBirth" logo to my web page as well as an installer notice advising of the SB framework install and possible conflicts.
Thanks again Eigentone!
Thanks again Eigentone!
-
- KVRist
- 277 posts since 3 Apr, 2007
In case anybody is curious, here are some of the generalized/slightly modified responses I have regarding some of these topics. Also, I only realized now that the license in the manual is different.
= Regarding PlugIn Sharing =
1) Naturally, SonicBirth includes a software license (presently GNU General Public License v. 2, aka GPL v2). Redistributing the binary* implies you have read and agree to the relevant portions of that license. I am not a lawyer and I don't pretend to be one. If you have any questions or concerns about the license for your territory or purposes, I recommend discussing them with a lawyer. Personally, I like the possibility for people to share and/or sell their SB creations, but that does not give them the right to do anything under the sun with SonicBirth's software/source. I don't know what Antoine Missout (creator of SonicBirth) thinks of sharing plugs (I haven't asked, specifically) - but I would assume he finds it acceptable since he implemented it and it is one of the things that makes SonicBirth unique.
The Current License can be read here:
http://sonicbirth.svn.sourceforge.net/v ... iew=markup
Of course, this link may change as the project changes.
The GPL V2 website:
http://www.gnu.org/licenses/gpl-2.0.html
Additionally, this License is taken from the user's guide:
==================================
1 License
Copyright c 2005, Antoine Missout. All rights reserved.
This software is provided 'as-is', without any express or implied war-
ranty. In no event will the author be held liable for any damages
arising from the use of this software.
Permission is granted to use a registration number you bought on
up to three computers you own.
Permission is granted to redistribute a plugin exported with Son-
icBirth, as long as the plugin is redistributed as it was exported,
without modification. Keep in mind that potential users will have
to download the framework from the official website.
==================================
IMPORTANT:
Although it was written when SB was a commercial application and has not been modified since, I believe it is still technically part of the license. Again, I am not a lawyer, and won't advise -- I am just pointing out the existence of this. Assuming this is in effect, you cannot provide the framework in an installer. I know of no public modification or retraction to this license.
2) If you do make money from your product and want to share or support SonicBirth in return, feel free to. Though if you do, I will refer you to Antoine Missout first. He has invested considerably more time, energy and expense in SB than I have.
3) If you do provide an installer* - there must be only 1 version of the SB framework in the framework search paths on any given configuration. If there are not, your plugin may encounter the aforementioned binary incompatibilities/version mismatches. Unfortunately, code loading details across 5 releases (Panther, Tiger (Universal), Leopard (Universal)) of OS X for 3 programming languages/binary interfaces (C++, C, Objective-C) for multiple executable types (applications, frameworks, AUs, VST...) cannot fit into 1 sentence so... providing the installer for a framework and getting the results you want will require some homework on your part (testing, reading developer documentation, etc.). If you are redistributing, the framework is your primary concern/source of conflict. As a starting point, there are several locations where SonicBirth.framework will be located and loaded by the OS. Your installer should search all of them and never install within /System/Library/Frameworks/. Researching this properly will take time if you want to publish excellent software. The technical primary documentation for this subject can be found at:
http://developer.apple.com/
If you're doing this commercially, I recommend reading the docs, discussing it at the SB forum, etc...
= Primary Info for Exporting as AU/VST and redistributing =
1) Framework (installed binary on user's machine) and export (binary version on your machine when plugin circuit is exported) versions should match. Other configurations have caused problems for users -- including 'very loud' or 'silent' problems. This means you should re-export the plugin for each framework version you export and release to your users. This also means there is the possibility that users are using different versions of the framework. SonicBirth includes a Batch Export function for this.
2) It is illogical (at present and probably for quite some time, given the number of developers presently on the SB project) to export your plugin without informing the user that they are using SonicBirth - if you want to provide an excellent experience for your users. I recommend this to anybody considering redistributing SB plugins (commercial or not). Since framework versions can cause problems for users. Meanwhile, binary compatibility issues have been and will continue to be a problem - we can attempt to resolve this for future releases but older SB versions will always be available.
The simple answer is to develop and test, while officially supporting a single version for your release (that would be the version you exported them with) and informing your user that the SB framework must match. If all distributors do this, there will be fewer problems (hopefully) due to better informed users and developers alike. This is a problem for some developers, because they want their plugin to appear and behave in an 'ordinary' manner. If you're doing this commercially, it's a risk you can't afford to ignore. Let your users know there are risks to binary mismatches when using SonicBirth, and that your product relies on SonicBirth. Personally, it and the potential consequences are far less irritating than some authorization schemes in use today. It's a fairly deep problem without a singular or simple solution at present.
3) If your installer updates the SB framework*, inform the user before installation and give them an option to cancel. Breaking another developer's plugins (which use the SB framework) will not go over well with users, particularly if you don't inform them you are updating. Remember, this could be as simple as a framework version mismatch.
If you provide an installer and inform the user of the plugins, your installer could recursively scan the directories for sbc files:
/Library/Audio/Plug-Ins/Components/
/Library/Audio/Plug-Ins/VST/
~/Library/Audio/Plug-Ins/Components/
~/Library/Audio/Plug-Ins/VST/
Where '~' denotes user's home folder
Once sbc files are found, traverse up to the component or vst and format the path for the user.
For example:
Good:
The following plugins may use the SonicBirth framework:
AudioUnit: Another Company's Distortion PlugIn
...etc...
VST: Friend's Plate Reverb
...etc...
If you require these plugins, download the release from (my) site for version (insert currently installed SonicBirth version), or check (the other manufacturers') websites for updates which are compatible with SonicBirth (whichever framework version you want to install).
Not very good, but better than no notification at all:
/Library/Audio/Plug-Ins/Components/Another Company's Distortion PlugIn.component/Contents/Resources/model.sbc
- or simply -
"At least one of your other installed plugins uses the SonicBirth framework"
If you do have an authorization scheme, be prepared to handle support for paying users who need to reinstall for this reason (that is, try not to integrate installation/version/authorization into the same files/units/procedures) -- so they won't have to be bothered to email you for a new license if they want or need to use a different framework version.
= Binary Versions and Distribution =
Here is a post regarding binary compatibility:
http://www.kvraudio.com/forum/viewtopic.php?t=2055 42
Here are the posts for the 1.3.1 releases, which describe the differences (scroll down for 1.3.1b):
http://www.kvraudio.com/forum/viewtopic.php?t=2035 44
As I remember, the first release of 1.3.1 used a more modern version of a resource file (nib), which was unable to load properly on some configurations. So, the 2nd release 1.3.1b had a fix for that and 1.3.1a should not be used for this reason.
Regardless of build version, test, test, test across multiple hosts, PPC/Intel machines and OS versions -- If you find a better version for your plugins which is not the latest, let us know (we also have an official bug tracker at sourceforge). If we know when a problem was introduced in version differences, it will help us locate it in the source.
= Calculating Latency Values For Exported PlugIns =
Logic 8 is mentioned here - this is an adapted response to calculating latency using Logic:
This is a finer point to designs which you'll want to get right. Whether you use samples or ms depends on your plugin, which elements are used, and their settings. Fortunately, you can just record an impulse and play it through the effect, recording onto another track to determine latency. Samples and milliseconds are both required - they are different units of measurement of time, which is a host/environment variable. Also, you'll want to make sure that you test this using multiple hosts, versions, and buffer sizes to ensure it is properly configured. You'll have to determine whether your plug requires 0, 1, or 2 of the latency adjustments units provided by SonicBirth. I find recording it easiest (provided your configuration is properly configured to begin with). Then just open the new recording in the sample editor and see how far it is off. Then see if the number varies based on environment (host, version, buffer size) - if yes, the you have to adjust ms (and counterbalance sample offset...). There's the starting point. If that makes sense in practice then the remainder of the process should come naturally. It's a lot like hardware/audio interface calibration, but more you have more variables to deal with, and you should try to be exact because inserting a plugin could then significantly alter phase relations of a mix, or an update with a correction could change their mix/balance significantly.
Finally, If you are using Logic 8, be aware that Logic silently switches tracks into high latency modes. Logic will often request such 'offline' tracks to render 2048 samples at once so... normally you'll want to enforce the stream is in low latency monitoring/playback. Otherwise, your calibration will be futile. You can also use sample and ms delays in Logic for interactive adjustments, then re-export and see if that is right on.
J
*If redistribution of the framework is acceptable/legal
= Regarding PlugIn Sharing =
1) Naturally, SonicBirth includes a software license (presently GNU General Public License v. 2, aka GPL v2). Redistributing the binary* implies you have read and agree to the relevant portions of that license. I am not a lawyer and I don't pretend to be one. If you have any questions or concerns about the license for your territory or purposes, I recommend discussing them with a lawyer. Personally, I like the possibility for people to share and/or sell their SB creations, but that does not give them the right to do anything under the sun with SonicBirth's software/source. I don't know what Antoine Missout (creator of SonicBirth) thinks of sharing plugs (I haven't asked, specifically) - but I would assume he finds it acceptable since he implemented it and it is one of the things that makes SonicBirth unique.
The Current License can be read here:
http://sonicbirth.svn.sourceforge.net/v ... iew=markup
Of course, this link may change as the project changes.
The GPL V2 website:
http://www.gnu.org/licenses/gpl-2.0.html
Additionally, this License is taken from the user's guide:
==================================
1 License
Copyright c 2005, Antoine Missout. All rights reserved.
This software is provided 'as-is', without any express or implied war-
ranty. In no event will the author be held liable for any damages
arising from the use of this software.
Permission is granted to use a registration number you bought on
up to three computers you own.
Permission is granted to redistribute a plugin exported with Son-
icBirth, as long as the plugin is redistributed as it was exported,
without modification. Keep in mind that potential users will have
to download the framework from the official website.
==================================
IMPORTANT:
Although it was written when SB was a commercial application and has not been modified since, I believe it is still technically part of the license. Again, I am not a lawyer, and won't advise -- I am just pointing out the existence of this. Assuming this is in effect, you cannot provide the framework in an installer. I know of no public modification or retraction to this license.
2) If you do make money from your product and want to share or support SonicBirth in return, feel free to. Though if you do, I will refer you to Antoine Missout first. He has invested considerably more time, energy and expense in SB than I have.
3) If you do provide an installer* - there must be only 1 version of the SB framework in the framework search paths on any given configuration. If there are not, your plugin may encounter the aforementioned binary incompatibilities/version mismatches. Unfortunately, code loading details across 5 releases (Panther, Tiger (Universal), Leopard (Universal)) of OS X for 3 programming languages/binary interfaces (C++, C, Objective-C) for multiple executable types (applications, frameworks, AUs, VST...) cannot fit into 1 sentence so... providing the installer for a framework and getting the results you want will require some homework on your part (testing, reading developer documentation, etc.). If you are redistributing, the framework is your primary concern/source of conflict. As a starting point, there are several locations where SonicBirth.framework will be located and loaded by the OS. Your installer should search all of them and never install within /System/Library/Frameworks/. Researching this properly will take time if you want to publish excellent software. The technical primary documentation for this subject can be found at:
http://developer.apple.com/
If you're doing this commercially, I recommend reading the docs, discussing it at the SB forum, etc...
= Primary Info for Exporting as AU/VST and redistributing =
1) Framework (installed binary on user's machine) and export (binary version on your machine when plugin circuit is exported) versions should match. Other configurations have caused problems for users -- including 'very loud' or 'silent' problems. This means you should re-export the plugin for each framework version you export and release to your users. This also means there is the possibility that users are using different versions of the framework. SonicBirth includes a Batch Export function for this.
2) It is illogical (at present and probably for quite some time, given the number of developers presently on the SB project) to export your plugin without informing the user that they are using SonicBirth - if you want to provide an excellent experience for your users. I recommend this to anybody considering redistributing SB plugins (commercial or not). Since framework versions can cause problems for users. Meanwhile, binary compatibility issues have been and will continue to be a problem - we can attempt to resolve this for future releases but older SB versions will always be available.
The simple answer is to develop and test, while officially supporting a single version for your release (that would be the version you exported them with) and informing your user that the SB framework must match. If all distributors do this, there will be fewer problems (hopefully) due to better informed users and developers alike. This is a problem for some developers, because they want their plugin to appear and behave in an 'ordinary' manner. If you're doing this commercially, it's a risk you can't afford to ignore. Let your users know there are risks to binary mismatches when using SonicBirth, and that your product relies on SonicBirth. Personally, it and the potential consequences are far less irritating than some authorization schemes in use today. It's a fairly deep problem without a singular or simple solution at present.
3) If your installer updates the SB framework*, inform the user before installation and give them an option to cancel. Breaking another developer's plugins (which use the SB framework) will not go over well with users, particularly if you don't inform them you are updating. Remember, this could be as simple as a framework version mismatch.
If you provide an installer and inform the user of the plugins, your installer could recursively scan the directories for sbc files:
/Library/Audio/Plug-Ins/Components/
/Library/Audio/Plug-Ins/VST/
~/Library/Audio/Plug-Ins/Components/
~/Library/Audio/Plug-Ins/VST/
Where '~' denotes user's home folder
Once sbc files are found, traverse up to the component or vst and format the path for the user.
For example:
Good:
The following plugins may use the SonicBirth framework:
AudioUnit: Another Company's Distortion PlugIn
...etc...
VST: Friend's Plate Reverb
...etc...
If you require these plugins, download the release from (my) site for version (insert currently installed SonicBirth version), or check (the other manufacturers') websites for updates which are compatible with SonicBirth (whichever framework version you want to install).
Not very good, but better than no notification at all:
/Library/Audio/Plug-Ins/Components/Another Company's Distortion PlugIn.component/Contents/Resources/model.sbc
- or simply -
"At least one of your other installed plugins uses the SonicBirth framework"
If you do have an authorization scheme, be prepared to handle support for paying users who need to reinstall for this reason (that is, try not to integrate installation/version/authorization into the same files/units/procedures) -- so they won't have to be bothered to email you for a new license if they want or need to use a different framework version.
= Binary Versions and Distribution =
Here is a post regarding binary compatibility:
http://www.kvraudio.com/forum/viewtopic.php?t=2055 42
Here are the posts for the 1.3.1 releases, which describe the differences (scroll down for 1.3.1b):
http://www.kvraudio.com/forum/viewtopic.php?t=2035 44
As I remember, the first release of 1.3.1 used a more modern version of a resource file (nib), which was unable to load properly on some configurations. So, the 2nd release 1.3.1b had a fix for that and 1.3.1a should not be used for this reason.
Regardless of build version, test, test, test across multiple hosts, PPC/Intel machines and OS versions -- If you find a better version for your plugins which is not the latest, let us know (we also have an official bug tracker at sourceforge). If we know when a problem was introduced in version differences, it will help us locate it in the source.
= Calculating Latency Values For Exported PlugIns =
Logic 8 is mentioned here - this is an adapted response to calculating latency using Logic:
This is a finer point to designs which you'll want to get right. Whether you use samples or ms depends on your plugin, which elements are used, and their settings. Fortunately, you can just record an impulse and play it through the effect, recording onto another track to determine latency. Samples and milliseconds are both required - they are different units of measurement of time, which is a host/environment variable. Also, you'll want to make sure that you test this using multiple hosts, versions, and buffer sizes to ensure it is properly configured. You'll have to determine whether your plug requires 0, 1, or 2 of the latency adjustments units provided by SonicBirth. I find recording it easiest (provided your configuration is properly configured to begin with). Then just open the new recording in the sample editor and see how far it is off. Then see if the number varies based on environment (host, version, buffer size) - if yes, the you have to adjust ms (and counterbalance sample offset...). There's the starting point. If that makes sense in practice then the remainder of the process should come naturally. It's a lot like hardware/audio interface calibration, but more you have more variables to deal with, and you should try to be exact because inserting a plugin could then significantly alter phase relations of a mix, or an update with a correction could change their mix/balance significantly.
Finally, If you are using Logic 8, be aware that Logic silently switches tracks into high latency modes. Logic will often request such 'offline' tracks to render 2048 samples at once so... normally you'll want to enforce the stream is in low latency monitoring/playback. Otherwise, your calibration will be futile. You can also use sample and ms delays in Logic for interactive adjustments, then re-export and see if that is right on.
J
*If redistribution of the framework is acceptable/legal
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
OK. I will discontinue including the framework. Is it OK for me to point potential users to SB site to download the app and I continue with the exported plugs?
-
- KVRist
- 277 posts since 3 Apr, 2007
Hi windwalker -windwalker wrote:OK. I will discontinue including the framework. Is it OK for me to point potential users to SB site to download the app and I continue with the exported plugs?
Sorry for the oversight wrt the number of licenses that SB is under. Again, I am not a lawyer nor in a position to say with certainty, but I *think* that is fine (after all, it is partly the point of SB). It seems to me that the current Licenses provide you to link to the SB site to download the framework, and that you can redistribute the unmodified exported plug. I believe you can also charge and/or accept donations for a plug, but it would be complicated to integrate authorization if the user must download a specific build of the framework.
Maybe one of the fellow SB users is comfortable enough with legalese to outline exactly what is possible (or not) in this regard. If you do find out, let the rest of us know, because I am sure other SB developers are/have been curious about this.
FWIW, I posted the long post above so the information would be available to all SB users - it may help them, it may save somebody's time, or it may start a good discussion.
J
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
Ok. Thank you so much for your responses. I will look into it further and weigh my options.
-
- KVRist
- 34 posts since 19 Jun, 2005
I've been considering making some of my plugs available commercially, as well. I believe we all need to agree on the procedure we're going to use. Basically, you'll need the user to download the most recent release of SB and install it. Then you should advise them to run the batch process on their SB-generated plugs. These should all be kept within a folder, which all of the SB developers should use. This way, if a user has 5 plugs from windwalker and 5 from me, they can easily make sure they're all using the most recent framework.
Somewhere on this site we need to create a sticky with guidelines for creating shared and commercially distributed plugs.
I would propose that we all advise end users to create a folder within their AU or VST folder called "SonicBirth" where any SB plug would reside. We all should further agree to provide a link to most recent SB release, with instructions for using the Batch function.
Maybe someone could write up a simple txt file that we could all include with our plugs?
(I would love to see SB 2 be able to create stand alone plugs, with no framework required, though I imagine this would be quite a rewrite!)
Somewhere on this site we need to create a sticky with guidelines for creating shared and commercially distributed plugs.
I would propose that we all advise end users to create a folder within their AU or VST folder called "SonicBirth" where any SB plug would reside. We all should further agree to provide a link to most recent SB release, with instructions for using the Batch function.
Maybe someone could write up a simple txt file that we could all include with our plugs?
(I would love to see SB 2 be able to create stand alone plugs, with no framework required, though I imagine this would be quite a rewrite!)
-
- KVRer
- Topic Starter
- 11 posts since 8 Jul, 2008
john,
I could not agree more with you and your process. It appears to be one of the best ways to minimize version conflicts. The only down side to any procedure we come up with is the amount of work on the customers end to get the plugs to operate. Creating folders, downloading additional applications, keeping all SB plugs in the SB folder, running plug batch export from SB each time you add a SB plug with newer versions is a considerable amount of work. I imagine that some potential customers would be put off by this. Still I think it will work and keep both customers and developers happy in the long run.
If we could have the cooperation of all developers that want to go commercial and provide one download site for an SB commercial install package kit which would include the most current version of SB that would be great. Also included in the Kit would be the instructions along with alias SB folders for vst and au plugs. We could even include a simple installer that installs the vst and au SB folders in the correct locations so all the user would have to do is install them and move the vst and au plugs to the respected alias.
Just for the sake of putting it out there... I wonder if it would be hard to create a separate application that could take the finished exported plug from SB and turn it into a fully self supporting au or vst. SB could then remain free and continue to gain users while the commercial conversion software for SB would carry a cost and/or license fees. This probably goes back to the same issues of converting to self supporting plugs in SB to begin with but I was just wondering.
Again I support and will comply with any unified means of distribution for SB plugs. Let me know how can help.
I could not agree more with you and your process. It appears to be one of the best ways to minimize version conflicts. The only down side to any procedure we come up with is the amount of work on the customers end to get the plugs to operate. Creating folders, downloading additional applications, keeping all SB plugs in the SB folder, running plug batch export from SB each time you add a SB plug with newer versions is a considerable amount of work. I imagine that some potential customers would be put off by this. Still I think it will work and keep both customers and developers happy in the long run.
If we could have the cooperation of all developers that want to go commercial and provide one download site for an SB commercial install package kit which would include the most current version of SB that would be great. Also included in the Kit would be the instructions along with alias SB folders for vst and au plugs. We could even include a simple installer that installs the vst and au SB folders in the correct locations so all the user would have to do is install them and move the vst and au plugs to the respected alias.
Just for the sake of putting it out there... I wonder if it would be hard to create a separate application that could take the finished exported plug from SB and turn it into a fully self supporting au or vst. SB could then remain free and continue to gain users while the commercial conversion software for SB would carry a cost and/or license fees. This probably goes back to the same issues of converting to self supporting plugs in SB to begin with but I was just wondering.
Again I support and will comply with any unified means of distribution for SB plugs. Let me know how can help.
-
- KVRist
- 34 posts since 19 Jun, 2005
Ideally, the SB framework would be written in such a way that older plugs would still work with it, without being updated. They might not take advantage of newer functions, but should still operate correctly. That way, we could design an installer that would always download the newest framework, and update the user's machine whenever they bought/downloaded a plug from an SB developer. We could skip the whole manual updating thing, and user could just put the plugs in the normal VST/AU folders.
Do you happen to know the reason that we're required to update plugs whenever a new framework is installed? I'm just curious, it seems it would solve a pile of problems if we didn't need to do the batch update thing.
Do you happen to know the reason that we're required to update plugs whenever a new framework is installed? I'm just curious, it seems it would solve a pile of problems if we didn't need to do the batch update thing.
-
- KVRist
- 277 posts since 3 Apr, 2007
It would require a lot of work. New developments and alterations are written to support this request, but removing the framework is not the current primary motivation for SB development. However, the changes that are being made are logical precursors for such a task. Finally, removing the framework would likely require other changes which could break compatibility (wrt custom UI) or require runtime hacks unless a SB plugin interface were made (requiring a few man weeks). So, we've low time to invest in development and we're currently in the middle of a different development phase.johnmck6: I would love to see SB 2 be able to create stand alone plugs, with no framework required, though I imagine this would be quite a rewrite!
Feel free to post and discuss 3rd party deployment blueprints like this. I'll try to help when I have time if I see a problem. One concern is that every 3rd party SB plug distributor would need to do significant testing and bug reporting of their plugin against next rev betas. If anything in a beta release breaks your plugin, you'd obviously want it caught before the public release. Naturally, we wouldn't want that to happen. The other general condition this carries is that the SB interface could get more complex, which could deter SB users.
johnmck6: Ideally, the SB framework would be written in such a way that older plugs would still work with it, without being updated...
I've extended versioning support in SB 1.5, so a lot of this should be easier. Writing a framework in this way has its consequences.
Example: Vista supports Windows executables from several different releases.
Is it perfect?
Is it small?
Is it simple?
Is it a good thing regarding code maintenance?
Will it require much more time to support 3 years of releases?
Is this good for everyone?
Does this make life better for users?
-- the context of SB --
Does this make life better for end user developers? (you)
Does this make life better for SB developers? (me)
How long are SB developers required to support a particular version and verify its correctness? The answer to this could cause problems if somebody's plug relied on an incorrect behavior.
(ask or discuss if an answer is not immediate)
In general, I agree with the ideal but (as you see) maintaining it can have its own problems. Sure, it can be done but if it were to happen it would be easiest on everybody involved to release it in a major update and then beta testers would have to be much more active.
By extending versioning support in this regard, elements in releases from this point on can support versioning. This allows the element programmer to open version 1 of their element if the archived sbc was created by SB 1.5 or version 2 (or version 2) if SB 1.6 was used. Of course, there could be complications regarding element instantiation. Often, versioning in this regard will promote whatever it is opening to the current format (it doesn't have to), so supporting versioning and extending it to work properly from many angles could eventually build up and would either silently promote or provide a more complex interface for you wrt archiving (which costs us a lot of time). Most of the elements that are available today won't change often, so it will not be a huge problem for a while. We're working on many low level things currently (when we have time).
Those are just some things to consider. I won't have time to implement this soon, but do continue the conversation -- it could improve design/implementation on our end.
J
