COCKOS
CONFEDERATED FORUMS
Cockos : REAPER : NINJAM : Forums
Forum Home : Register : FAQ : Members List : Search :

Go Back   Cockos Incorporated Forums > Other Software Discussion > WDL users forum

Reply
 
Thread Tools Display Modes
Old 03-05-2010, 12:40 AM   #1
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default contribs: (perharps) we could (try to) propose that (may be) ?

It seems there are motivated contributors (and great contribs!), here.
I'd like to do so.. but I seriously hacked my IPlug.. win only.. tied to another Open Source..

I see most of the contributors "hacked" their IPlug too and so, "released" it modified (which is ok with wdl licensing, though).

btw, it's difficult to integrate those contribs, and I don't even talk about merging 3rd party mods with yours.
In fact, execpt some pure IControl contribs, I didn't integrate them because of that.
I don't follow WDL updates because of that too.
technically, I think those mods are also due to the "difficulty" of inheriting the whole IPlug things: IPLUG_CTOR, private/protected scopes, etc.. (I started to work on that, I just have the IPlug inheritance, i.e. the "IPlug" class, so all my plugs inherits from another class but I won't be able to go back to it for a while) and, anyway, IPlug (the whole stuff) needs some mods to be inherited.

don't you think it could be great structure a bit all those contribs ? so that we can really use them and participate as we can/want ? IPLug is already an open source but, assuming it's turn into something "inheritable", I'd like to see a repository for the contribs "over IPlug", SVN/CVS tools..
.. don't you ?

(perharps) we could (try to) propose that (may be) ?
Jeffos is offline   Reply With Quote
Old 03-05-2010, 04:48 AM   #2
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

+ 1!

I am trying to keep track of all the changes i make but it's a nightmare! If the whole thing was on a public scm system, this might be simpler.

I'm dreading the day when cockos update their distribution with some cool new stuff and i have to go back and manually re-enter my mods.

oli
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Old 03-05-2010, 08:53 AM   #3
RRokkenAudio
Human being with feelings
 
RRokkenAudio's Avatar
 
Join Date: Jun 2009
Location: Buffalo, NY
Posts: 777
Default

++++1
RRokkenAudio is offline   Reply With Quote
Old 03-05-2010, 02:31 PM   #4
DukeRoodee
Human being with feelings
 
Join Date: Jul 2009
Posts: 20
Default

+1 also... i think we should wait for a statement / opinion of the "officials" (i guess this is "schwa", right ?) before we start some doubtful initiatives.
The biggest problem i see at the moment is not merging or versioning all the private contributions because in fact this can be organized... it´s more like (olilarkin said it already) when there is a new iPlug release you have to merge everthing with a new "core". A few day ago i tried to get an overview how to merge my version with the Nov2009 release...mmmh... yes, at the moment possible but who knows what brings the future. I´d really like to see a contribution between the authors of iplug and the comunity but this would be a matter of discussions....

regards
Rudi
DukeRoodee is offline   Reply With Quote
Old 03-05-2010, 03:08 PM   #5
Astralp
Human being with feelings
 
Join Date: Dec 2009
Posts: 73
Default

It would be great I agree, I was dreading moving to the great cc mod as I've hacked and added quite a few bits, but it was surprisingly easy with winMerge, took me less than half an hour. It would be great to have some type of plugin architecture, where functionality can be added easily. Although at the moment I am clueless on how this could be done...

Really, I think there are 2 parts to the additions, elements that are universally useful, like the midi channel, the mac missing parts etc... It would be nice if these could become part of the official core. The second mentioned above, additional/optional functionality as a plugin format.

It's great that this project is alive and actively used/contributed, it is incredible.
Astralp is offline   Reply With Quote
Old 03-05-2010, 03:12 PM   #6
Astralp
Human being with feelings
 
Join Date: Dec 2009
Posts: 73
Default

oh, what i also meant to say was that if everyone's mods can make it into a single unofficial version, if there is a new release, at least it will only have to be updated once by one person. Hope that makes sense!
Astralp is offline   Reply With Quote
Old 03-05-2010, 04:24 PM   #7
olilarkin
Human being with feelings
 
Join Date: Apr 2009
Location: Berlin, Germany
Posts: 1,248
Default

If it was ok with cockos we could have one "community" version on a public scm.
__________________
VirtualCZ | Endless Series | iPlug2 | Linkedin | Facebook
olilarkin is offline   Reply With Quote
Old 03-05-2010, 04:33 PM   #8
Astralp
Human being with feelings
 
Join Date: Dec 2009
Posts: 73
Default

I've just been having a play around with an idea which is to create a contrib directory inside the IPlug folder. In this folder will be 3 equivalent files for each of the IP files:

IPlug/IGraphics.h //Usual files
IPlug/IGraphics.cpp

IPlug/contrib/_IGraphics.h
IPlug/contrib/_IGraphics.cpp
IPlug/contrib/_IGraphicsClass.cpp

_IGraphic.h includes ../IGraphic.h and contains any custom includes such as #include<vector> for example...

_IGraphics.cpp includes IGraphics.cpp, and is the place for any custom functions

_IGraphicsClass.h is included by IGraphics.h at the end of the IGraphics class itself, and so would contain something like:

public:
void myCustomFunction();

Using the above additional changes can be kept out of the main system, and it is easy to keep track of what has been added. The only change required to make this happen is a single include inside each class header.

The one snag I have found in my test is that it seems impossible to add object declarations...

I think I'll adopt this method for myself anyhow seeing as I'm doing it, it would be good to know what others think? It is someway towards a plugin architecture I think.

If others are interested I'll set up a 'blank canvas' with the release version.

I hope the above makes sense!

UPDATE: hmmm actually it isn't working, it compiles but the functions are missing...

UPDATE2: I have it all working now, it seems quite an elegant solution to me for any non-core changes and adding any 3rd party functions/contributions would be fairly painless. I'll upload an example once I've finished.

Last edited by Astralp; 03-05-2010 at 05:53 PM.
Astralp is offline   Reply With Quote
Old 03-06-2010, 12:40 PM   #9
Astralp
Human being with feelings
 
Join Date: Dec 2009
Posts: 73
Default

After many Long hours I think I've come up with a solution to added code, so making the plugin side of things easier to handle, with little impact on the core.

I did explain above but I'll do so again, hopefully making it clearer.

Firstly, the only addition required to the SDk is one #include in each header file, at the bottom of the class declaration. This allows adding extra function/variable, object declarations etc... The only other requirement is to add an #include to the _CustomControls.h in your project cpp.

How it works is that for each .h and .cpp pair, there 3 equivalent files which live in the 'contrib' subfolder. So for example for IGraphics there is:

IPlug/contrib/_Igraphics.h
IPlug/contrib/_Igraphics.cpp
IPlug/contrib/_IgraphicsClass.h

The _Igraphics.cpp holds functions which belong in IGraphics.cpp, and the function declarations are put into _IgraphicsClass.h. _Igraphics.h is used to put any extra #defines or #includes required. That is all there is to it for the most part.

There is an exception to the above which is _CustomControls.h and .cpp, this is just a place to keep added controls out of the core.

I think the beauty of it is that to release a 'plugin' you can just provide the _<whatever>.h, .cpp and _<whatever>Class.h only containing the plugin code. Then the end user has to just copy paste to their own contrib files, which can of course contain their own private additions too.

The included file uses the CC release as it's base as I think there are many essential fixes/additions to the core (thanks CC for those). The only thing I have done is move the cc controls into _CustomControls.h and .cpp. I've also added popupmenu and a couple of other functions to demonstrate usage in _IGraphics.x. Oh I also moved cc's SetFromStringAfterPrompt to the _IGraphics too...

Anyone not wanting to use the cc base, can easily just add the include statements to the cockos release. As long as those are the there the entire contrib folder should be transferable, well that is the whole idea anyhow!

IMPORTANT! - In your main project cpp, you must include the _customControls.h just below the IControl include:

#include "../../wdl/IPlug/contrib/_CustomControls.h"

Obviously you also need to add all of the contrib files to your project too.

I hope that people have a serious look at this, I am using it now, and have moved all of my changes/hacks across. I've decided to make a big effort not to touch the core when possible, and where I have altered the standard controls, I have now made new controls to reflect the changes, what a good boy I am It took hours of messing about to get all this working, but now I feel like I've just hoovered the house, and can relax about future IPlug versions...

Be sure to back up your existing IPlug, I can't be held responsible for any explosions... Oh, finally i haven't done any examples as i use codeblocks, so prob wouldn't be any use to anyone else, but it *should* be identical in usage to the cc, apart from the popupmenu and extra couple of functions i added to the contrib files...

Andy
Attached Files
File Type: zip IPlug-Proposed-plugin-Framework-CCbase.zip (135.4 KB, 188 views)
Astralp is offline   Reply With Quote
Old 03-06-2010, 02:47 PM   #10
Tale
Human being with feelings
 
Tale's Avatar
 
Join Date: Jul 2008
Location: The Netherlands
Posts: 3,645
Default

Not that I don't appreciate what you guys are trying to do, but...

Actually I'm quite happy with IPlug as it is. It would be nice if some of the contributions are eventually included in the "official" release, but personally I don't really see why we would need a system for this. IMHO contributions should be separate source files, and they should certainly not require any changes to "core" files.
Tale is offline   Reply With Quote
Old 03-06-2010, 10:15 PM   #11
RRokkenAudio
Human being with feelings
 
RRokkenAudio's Avatar
 
Join Date: Jun 2009
Location: Buffalo, NY
Posts: 777
Default

k this is getting confusing now lol...

Can't we have like Showpopup.true("this is a popup tooltip");

JUCE is reall slick like this

~Rob.
RRokkenAudio is offline   Reply With Quote
Old 03-07-2010, 12:17 AM   #12
RRokkenAudio
Human being with feelings
 
RRokkenAudio's Avatar
 
Join Date: Jun 2009
Location: Buffalo, NY
Posts: 777
Default

Also, if not too hard, could you put example usage in the commented section in the .h files? like what the arguments will look like attactchcontrol(something,something, something);

~Rob.
RRokkenAudio is offline   Reply With Quote
Old 03-07-2010, 04:08 AM   #13
Jeffos
Mortal
 
Jeffos's Avatar
 
Join Date: Dec 2008
Location: France
Posts: 1,969
Default

Sorry, Rob I'm in a rush.. but I definitively have to put some words !

First, I'm glad to see I'm not alone thinking that + intertesting opinions + big, Big, BIG thank yous to Alstrap!! I like your idea: simple, efficient! This is a very good start, and with CC greatest hits moreover!

I'm quiet sure we can sort this stuff out without bugging schwa (too much )

The only pb I can see with this idea (well, say "I can feel", as it'd be better to dig into the code before saying that, but not possible before a few days...) is that it's OK to add things, not to mod them. Or, for that cases, are you thinking to comment stuff in "../IPlug/CoreStuff.cpp" and implement them in "IPlug/contrib/_CoreStuff.cpp" ? I'd really prefer inheriting things (0 mod), but I agree it's way much less worse than hacking the core directly!

Quote:
Originally Posted by Tale View Post
Not that I don't appreciate what you guys are trying to do, but...

Actually I'm quite happy with IPlug as it is. It would be nice if some of the contributions are eventually included in the "official" release, but personally I don't really see why we would need a system for this. IMHO contributions should be separate source files, and they should certainly not require any changes to "core" files.
I agree with Tale, my idea in the OP was also contribs "over IPlug" without any mod to the "core" (the idea). Fix propositions apart, of course.
That said, Tale, I started to dig that way: IPlug core would need slight updates so that we would be able to put things "over it". Also, if we find/agree on a way to work "over IPlug", then, I think a public scm for those and only those contribs would be great (if cockos ok, of course, hence the title of this thread), don't you ?

Quote:
Originally Posted by Astralp View Post
It's great that this project is alive and actively used/contributed, it is incredible.
++1 ! So, let's be constructive, let's dig the code!
I'm gonna take a true life example and see if/how I can integrate it over Alstrap's proposition. bvesco's improved font rendering is a good candidate (http://forum.cockos.com/showthread.php?t=31080, basically allows different fonts in a same plug): win only, IText is a struct and that I have no way to test impacts on the Mac side.
.. I need "some time", though (and I wish myself "good luck" )
Jeffos is offline   Reply With Quote
Old 03-07-2010, 06:20 AM   #14
Astralp
Human being with feelings
 
Join Date: Dec 2009
Posts: 73
Default

I too would prefer as little interference with the core as possible, but it is often necesary to add functions to the IGraphics class as an example,
; the function I added to update the param from GUI as an enum. Yes it could be added as an inheritance class, but really that is where it belongs. So the thing I like is that it is also like a proposition to be added to the core, presented in a simple manner.

I think that one of the most important things to bear in mind is that users have very different levels of programming experience, and having a non-destructive, yet simple way of adding features, will a; make it easier for less experienced programmers and b; also encourage everyone to think of how to add things in a non-destructive way.

Not sure I would use it, but I like the idea of the popup tooltip and had a quick look at the code, but it uses additions to the main IControl draw(). I would be interested to see if Roodee could redevelop it in a non destructive manner, for example an inherited draw which then could be inherited by custom controls that the end user wants to use it with. It could then also be released as an addon for the above framework as opposed to having to download the entire hacked core

As for commenting out, I think that should be avoided if possible, my solution certainly doesn't cover every angle, but it has tidied up my corner quite well, even if nobody else uses it I will carry on with it I think, it's nice having all of my edits outside of the core especially now I understand the structure better after a couple of months worth of use.

Just to say again, i think the most important aspect of my proposal is to encourage people to think of non-destructive ways of adding bits n bobs regardless of programming experience, hopefully meaning more users and more addons coming forward. I think that the single include added to each header is worth the price.
Astralp is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 09:41 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.