Continuing the discussion from Wavelab && 2015-12-1 VST plugins: Removed old but flawed workaround for detecting offline mode:
To let this not drown under a completely unrelated topic I suggest to continue this idea here…
1 Like
(basically repeating the content of my post in the other topic so that it is in this discussion as well, well thought @daniel)
In the other thread It was suggested to make it a public Google Doc where everyone can collaborate, but I don’t think it is a good idea: for me it is too high the risk that this will transform it into a makeshift (and poor) bug reporting system: what one sees as one particular host’s quirk, could in reality be a JUCE bug and vice-versa.
Locating it in the git repo is better IMHO also because it makes it is possible to track its history easily and relate it with fixes/workarounds in JUCE: when one clones/updates the tip, this document will contain the up to date list for the particular version that has been downloaded.
I’d start by putting in it the remarks on various hosts and formats that have been added at the bottom of the multibus guide post: that seems to me like the perfect style for that document to have.
Google docs can track the history of the document. Also, I can make the google doc editable only for specific people (I could pm people on the forum and specifically give these people access).
In no way should the doc be a bug reporting system. In fact, I don’t think it should have anything to do with JUCE per se. It just be a list of known quirks and behaviours of DAWs. For example:
- the first process call sent to a VST3 in Sonar will always have all buffers pointing to a nullptr.
Such a doc could also be useful to non JUCE users and I think it should be completely separate from bug reports.
Sure, but that is not as easily accessible as it is for a file tracked by git, right?
At that point, you could simply copy and paste their contribution into the doc rather than bothering to grant them access… the way you propose to do that doesn’t seem much faster (this has just sparked an idea in my mind, more on that later in the post)
I totally agree, and I haven’t said it should be. I have said that it may end up being one if users mistake JUCE bugs/issues for host strange behavior.
Take the case of the recent issues with Cubase 8 and the muting channel, or the issue with sidechain and AU that I have lately reported (by the way, has it been fixed?): is that a quirk of the calling host, or a bug in JUCE that is not dealing with it properly?
I don’t agree with this at all: we all are very JUCE-minded people and it is inevitable to reason also in terms of JUCE methods. It may also be very convenient to include that in the document, for example:
- In Host XYZ, processBlock() may be called with zero samples a number of times before prepareToPlay() is called (just made this up, to make my point).
It would be very hard to read this in terms of native VST or AU methods, and one would do a disservice to the JUCE community by translating them to native SDK terms on purpose.
The idea I had earlier in the post:
If you ever decide to put this on github, either in the JUCE repo or in a repo by itself, perhaps the best way to review and then take in user contributions could be to finally accept those pull requests!
I also think, that a place to exchange knowledge about certain hosts but also about certain platform behaviour is needed. There are several topics, the ones mentioned when using the juce sdk, but also the connection between deployment target and language dialect, and other stuff.
It is certainly different from bugs, and does not belong into an issue tracker, as it’s not something that can be solved (and will not vanish).
A shared document is a starting point, but there are so many tools around, I think it would be stupid not o use them.
I would really propose to run a wiki, maybe even like in wikipedia with a front layer and linked discussions.
I know, this is additional work to set up, but as @fabian pointed out, it would be also useful for non-juce users and therefore it might attract additional people to juce, so it should be worth the effort…
I even think there are issue trackers around, that use already the combination of wiki and issue tracking, so maybe take that into consideration, I think traq was one of those IIRC. That way you have these two kinds of information available and the users need only one additional account.
A major benefit would be to have a something where you direct people with common problems to, instead of writing the same answers in the forum over and over again. And linking to a place in a googledoc sounds not very reasonable to me. It’s kind of DRY
On a second thought after my initial position, and after reading @daniel’s contribution, I’d like to take back my support for the idea of a document in the git repo.
Most certainly, that would force it to be a plain txt file, which may not be expressive enough.
For example, you can’t put there a readable and maintainable comparison table of hosts for some aspect, which certainly would come handy at some point.
I like the idea of the wiki better than the GoogleDoc, the integration with a bugtracking system is also a plus.
If the JUCE team (or their web team) is not willing to invest much time now to install something like traq (is it the same as trac?) on their server, it is still possible to make experiments in that direction because GitHub provides both the bugtracking and wiki feature.
This has been mentioned a number of times already in the forum, I don’t get why it isn’t being experimented yet.
The only practical reason that has been mentioned by @timur in another thread is that integration with the other developers within ROLI is stopping them.
This doesn’t sound right to me because whatever system they are currently using internally, they can continue using it privately, switching to GitHub bug-tracking and wiki only for the open-source / public stuff.
Don’t overcomplicate things, a simple txt-file inside a git-repo, enough.
Sonar:
issue1
issue2
Wavelab:
issue1 (fixed since version 1.2.3)
issue2
etc…
1 Like
That’s enough as a reminder for things, you already knew and want to go through a checklist. But it is certainly not enough to explain things in there.
And also I don’t think it will withstand a collaboration, where every author has a different idea, how to explain, how to layout and how to structurize things.
So finding things there and finding the correct spot where to place the information, would probably take too much time for me and stop me from collaborating there…
I think the information there should be easily accessible and linkable. And this is technology you don’t need to invent, it’s there.
1 Like
Perfect is the enemy of good, why we need always the newest technology to solve the simplest problems, why not an easy plain text file. Yes somebody has to care about this, merge the pull-requests, thats all. We can begin in 10 seconds, we don’t need to setup a wiki, we don’t need a google/facebook account. We don’t need html. Its all there.
I agree that is a good idea to start already collecting information in whatever is accessible, e.g. a text file. But I wouldn’t lose the goal of a better structured, easier accessible and linkable place.
Propose a place and start writing, eventually it becomes the necessary spin… If your attitude is don’t talk but do, then do 
You can link to files in a github repo very easy.
We can also use the md file format, which allows formatting the test
https://github.com/julianstorer/JUCE/blob/master/ChangeList.txt
Great idea! As a host developer I would also like to note strange none-juce plugins.
As for medium, Can’t we just create a sticky-topic in this forum and be done with it?
Some moderation would be needed from time to time, but I like the idea of having it all in one place.
If not possible, I vote for git + txt
So do I, but the forum is not suitable IMHO, because it shows the line of a discussion, I need to read to the end to get a complete idea of the issue. And also sometimes the experiences morph with further posts.
As an example, if you get in trouble with Multibus layout, you have the very helpful sticky from fabian, but it is a long story to read. And who says, that all information along the discussion is still valid? If I think after reading the half, I understand it, who says, that in the second is not statet the opposite, because things turned out to work better another way?
What I want to have in the end would be a page/txt/… to describe the current knowledge about that issue/behaviour and the possibility to get maybe further information from a thread, when I want to retrace where this insight comes from.
Using the forum together with that info is a route wich could be very helpful IMHO.
Thank you for your comments and sorry for the delay.
I think having something in the repo would be nice but we have decided to first give it a try as a google doc and see how things play out. We will then move it to the repo if we feel that it contains valuable information.
You can find the doc here. I’ve only added one observation right now and will slowly be migrating our internal doc to the public one.
If everyone in this thread (and anyone else who is interested in contributing) please pm me their google account e-mail - so that I can share the doc with you with editing enabled.