IPlug Community effort

[olilarkin]

Despite the fact WDL is "in the wild" and changes are trackable on git (which i think is a very good move), IPlug hasn't changed much for the last year or maybe longer. I would love to see a more feature complete version of IPlug. The majority of the changes on the Cockos git repository lately are to do with reaper stuff and since it seems like IPlug was schwa (and scott stillwell's?) baby originally I can imagine that nowadays other things take precedence (i.e. reaper 4).

A few of us are working away on our own modded versions but by pooling our collective efforts and opinions about how things should work etc, we could create a more feature complete, standard "community version" that would benefit everyone and make the framework much more appealing for other developers. This in turn would increase the amount of people fixing and testing stuff. I think new IPlug users will often mistrust an individual's branch of the project, where as a community version would appear safer.

Here is a list of things that i think are missing from the Cockos IPlug version or need some work. Various people have fixed many of these things in their own ways, but still, to make a community version such things would have to be agreed upon.

- Text display (different fonts, osx/win should look the same)
- Text input
- Popup, contextual menus (with style options like vstgui)
- Seperate PromptUserInput() from the notion of parameters, so it can be used for other stuff
- IGraphicsLice to IGraphics merge (see schwa's post below)
- Cocoa class name conflicts
- Program/Preset manipulation from the plugin (i spent today adding this one).. i.e. renaming and selecting programs from inside the plugin gui
- OSX file selection
- OSX color chooser
- Better ide projects/makefiles
- 64 bit support
- Some effort to reduce the number of compiler warnings and to comply to the latest standards i.e. gcc's warning about &IRECT etc
- better example projects demonstrating all the controls and features
- state saving / serialization
- documentation!!!

some things that i think would be a lot more work, but nice...

- vst3 support
- RTAS support
- linux ladspa/lv2/dssi? support

anyway, what do people think about it? anything to add to the above lists? I'm not sure how difficult it would be to manage this kind of thing and how it would work, since i didn't work on a collaborative open source project before.

let me know,

oli

[cc_]

For me ideally these things would get into the Cockos repo. But as that doesn't seem to be happening a Community effort is the next best thing, so I'd support it.

[bvesco]

If this is going to happen, I would love to see it get on github and adopt a "standard" open source workflow with peer reviews and a central "committee" (made of just a few of us) that approved all changes that made it back into the main branch. With that in mind I would also like to see it follow a formal process of pull requests and reviews.

I would be happy to participate in getting that process set up.

[olilarkin]

If this is going to happen, I would love to see it get on github and adopt a "standard" open source workflow with peer reviews and a central "committee" (made of just a few of us) that approved all changes that made it back into the main branch. With that in mind I would also like to see it follow a formal process of pull requests and reviews.

I would be happy to participate in getting that process set up.

that all sounds great to me

[olilarkin]

so nobody else is interested?

[Jeffos]

As I said before, I very am too Oli! But I'm not sure I would participate on a regular basis (my main prob here is time..)

[ArdeII]

So small user base here ;)
I would like to participate but I don't have the skills nor time ;(

[Adam Fulara]

I'm interested, especially in 64 bit version of IPlug.

[bvesco]

This will be a little hit and miss until we get into a groove, but here is a repo ready to go:

https://github.com/b-vesco/wdl-ce

Primary task for those that want to contribute:

Create a github account

Add yourself to the membership page in your desired slot.

You may need to wait for me to add you to the project to follow some of the directions below...

Go to the github project, find the pull request, follow the instructions.

There is also a starting "guidelines" page on the wiki at github.

After reading the pull request and the guidelines, make sure to visit the wiki "membership" page and add yourself to the appropriate category based on your level of interest for helping with the project.

P.S. Don't commit any code to anything yet. Let's not get ahead of ourselves and give it another week or so to establish some best practices for the repo. Being that we're using it in "free" mode we don't have a lot of admin capability so we're going to need some self control to keep things tidy.

[olilarkin]

good work bvesco,

I am a little confused by the number of different branches at the moment. Are they just inherited because you cloned the whole cockos repo?

also i think if it's possible it would be good to have a url more like

https://github.com/wdl-ce

but i guess it doesn't matter so much,

oli

[bvesco]

Did you make a github account? I'd like to add you to the repo. I expect your name to show up on the list of directors ;)

I agree on the name, but with a free account our hands are tied in that regard. A good thing about got is that if the project grows to warrant more dedicated hosting it is trivial to move the whole repo with history intact.

Number of branches? It was my best guess at what we want for now. Branches are just pointers in git so can be created and deleted with no overhead.

[Guod3]

Very good initiative!
I don't think I have the prerequisite wisdom to provide much guidance but will watch with great interest.
The value added features will be very useful to my own plugs, and it will be good to get some insight into how a well designed library is grown!

[Tale]

so nobody else is interested?
Well, I am interested. However, I don't think I will be contributing anything directly. I already maintain and share my own customized WDL Git repository (which I have to do for myself anyway, so this is not much of an effort), and I track some of you guys' repositories. At this moment a community repository wouldn't add much IMHO; not for me personally anyway.

[olilarkin]

ok, i created a github account and added myself to the list.

Well, I am interested. However, I don't think I will be contributing anything directly. I already maintain and share my own customized WDL Git repository (which I have to do for myself anyway, so this is not much of an effort), and I track some of you guys' repositories. At this moment a community repository wouldn't add much IMHO; not for me personally anyway.

it would be good to have you on board. I expect we'll be including quite a few of your changes

personally, i have a plugin that is just about ready to be released based on my modified WDL, so i will keep two separate versions. Hopefully if the WDL-CE takes off i can move to that at a later date.

[bvesco]

Tale

The primary goal would be to be able to share our changes with each other and the community in a more structured and controllable fashion. The current model of us each having our own repo is not the best. One example is recently I tried to incorporate some OSX input code from one of the other repos currently available. Not only is it somewhat buggy, but I can't be sure it was committed atomically so there may be unrelated code that I had to take in order to get it. It also means I have to accept that the code is fine with no peer review or other process to offer some guarantee of quality. If there's not a lot of support, desire or need for a community version then it will eventually just wither and die. I think it benefits all of us to make this happen, but it is certainly much easier to not make it happen. It would certainly if nothing else be fine if you want to transfer your repo into the community edition and keep your WDL mods there in your own branch. github at the very least maintains a high degree of reliability in terms of keeping your repo up and available "forever" even if you personally change hosts or stop paying for your web space for one reason or another.

[olilarkin]

can those who are interested in participating join github and add themselves to the membership list on the wiki? I am quite keen to get started, github looks like geeky fun

a few questions for bvesco...

-could you explain the purpose of the various branches? dev, candidate, release, cockos-master, cockos-next & candidate

-I would have thought we'd start from the current cockos master no?

-what kind of things shall we discuss here, vs on github?

-I would like to add my list of things above as a wiki page, and perhaps we can group them by priority and start creating "issues" for some of them. What do you think?

-Is the idea that you create a branch for fixing each issue separately and then submit a pull request?

[bvesco]

-could you explain the purpose of the various branches? dev, candidate, release, cockos-master, cockos-next & candidate

Dev: some generic place to do generic stuff, probably we won't use it. Candidate: a release candidate, the place we would do topic branches off of and pull requests into. Release: the official release branch, pulled from candidate whenever we decide to do official releases. Cockos next and master are mirrors of the cockos repo.

-I would have thought we'd start from the current cockos master no?

No, our next stable release starts at Cockos' last stable release. Likely we will end up pulling everything Cockos does into our own candidate branch, but not blindly.

-what kind of things shall we discuss here, vs on github?

Discuss everything here. There is no forum on github. Pull requests and code reviews happen on github, in their appropriate places.

-I would like to add my list of things above as a wiki page, and perhaps we can group them by priority and start creating "issues" for some of them. What do you think?

I don't know if a wiki page is necessary. Make issues for the features you would like to see addressed. Every feature is worked on in its own topic branch off of candidate. Every feature should have a pull request that goes under official review before being merged into candidate.

-Is the idea that you create a branch for fixing each issue separately and then submit a pull request?

Yes, see above.

The first "work" I would recommend is going through the cockos changes and evaluating them for inclusion to our own candidate. We should also figure out what the release schedule is for the community edition. Do we release whenever we feel like it? Do we release once a month? What are the criteria for determining if a release is stable enough to be a release?

[olilarkin]

thanks for all the answers,

The first "work" I would recommend is going through the cockos changes and evaluating them for inclusion to our own candidate.

as far as i can see there are only a few that relate directly to IPlug. Some Lice related ones are probably necessary and some maybe some swell (although i don't think there is much of iplug that relies on swell). The problem is that Cockos are supposedly testing these changes with the latest reaper builds, and we don't have an application to test most of the changes with, or a reason to, as plugin developers.

We should also figure out what the release schedule is for the community edition. Do we release whenever we feel like it? Do we release once a month? What are the criteria for determining if a release is stable enough to be a release?

I think we need a better example plugin (or a few) as a kind of test suite to evaluate the community edition. When these are working properly we could do a release. Since not many people seem to be interested in participating I don't think we should commit to any schedule.

I would like to propose that for this new example plugin we switch to a project that doesn't link to static libraries like the cockos example. I have switched to this approach which, although taking slightly longer to compile afresh, has saved me a massive amount of time when modifying and debugging IPlug code. Also it has allowed me to define IGraphicsCocoa on a per plugin basis using a preprocessor macro, solving the class name conflict.

[schwa]

I signed up :)

Fwiw, the biggest thing I would change is combining IGraphics and IGraphicsLice, removing all of the drawing methods, and simply exposing the lice bitmap to the plugin implementer. When iplug was written, lice did not exist (the original implementation used GDI+, which is why the abstraction between IGraphics and IGraphicsLice exists.).

That change would remove a bunch of pointless pass-through code, and make plugin drawing far more flexible. The coder could just call Lice functions directly.

[Jeffos]

^^ I exactly did that (w/o caring too much about OSX though) and it's one of the reasons why I don't follow IPlug updates for a long time..
The first "work" I would recommend is going through the cockos changes and evaluating them for inclusion to our own candidate.
don't you think WDL updates (out of IPlug) should always be included in "blind mode" and rather adapt the IPlug OS code if needed ?

[olilarkin]

I signed up

great! you can keep an eye on us ;-)

Fwiw, the biggest thing I would change is combining IGraphics and IGraphicsLice, removing all of the drawing methods, and simply exposing the lice bitmap to the plugin implementer. When iplug was written, lice did not exist (the original implementation used GDI+, which is why the abstraction between IGraphics and IGraphicsLice exists.).

this doesn't look like too much work at all.

oli

[bvesco]

Schwa, I don't see you on the wiki membership list and I can't for sure locate you on github.

[bvesco]

Oli,

See https://github.com/b-vesco/wdl-ce/pull/2

I know we're talking about somewhat blindly pulling all non IPlug WDL changes from Cockos. This definitely falls in that bucket. This is to get you used to the process.

Oli, please do this:
1. view the pull request at https://github.com/b-vesco/wdl-ce/pull/2
2. Feel free to comment on the code if warranted
3. On a line by itself, place the single word "Approve" or "Reject"
4. Note that I already voted with my "Approve" in a comment, you should also vote approve or reject.

Since we are the only two currently listed community managers, once you have also voted "Approve" we can consider this pull request approved. Currently I am the only merge master, I'd like to see how you feel about doing merges sometimes. First, only merge things that have been properly pull requested and peer reviewed by a majority of active community managers (you and me right now). Once you comment, we agree this can be merged. There's a button on the pull request that says, "merge help" which shows the git commands you need to run to complete the pull request. Once you run those commands you should be able to refresh the page and see the pull request is closed. Never manually close a pull request by clicking the "close" button. DO NOT close pull requests with anything other than git commands!

[olilarkin]

Currently I am the only merge master, I'd like to see how you feel about doing merges sometimes

I am happy to be a merge master too, better to try it now in case i mess it up!

[olilarkin]

I agree on the name, but with a free account our hands are tied in that regard. A good thing about got is that if the project grows to warrant more dedicated hosting it is trivial to move the whole repo with history intact.

it turns out you can get the url i suggested with a free account by creating an organisation:

see https://github.com/wdl-ce/

but since there can be a few projects the url is actually https://github.com/wdl-ce/wdl-ce !

Do you still think this is better? I think that for a community project it's nice to have a name thats not linked to a user, but as I said before, it doesn't matter that much. I will delete the forked one if you disagree.

oli

[schwa]

Schwa, I don't see you on the wiki membership list and I can't for sure locate you on github.

I am "schwaaa" on github. What is the wiki membership list?

[bvesco]

https://github.com/b-vesco/wdl-ce/wiki/Membership

[pylorca]

How about documentation? doxygen style: http://en.wikipedia.org/wiki/Doxygen

[bvesco]

pylorca, are you volunteering to take on a documentation effort? I can get you started with a git topic branch if you are interested.

[olilarkin]

bvesco - can you explain the two new branches pr1 and pr2?

thanks,

oli

[Cubits]

Im currently using iplug and would be great to see an effort into making it more usable and with help from the devs i would contribute in ways i can mainly getting some documentation going.

-Kieran

[omijim]

I'm quite interested in contributing to the IPlug (and WDL) community-source project.
In the past (throughout the 90's) I've built quite a bit of MIDI and music software in C++ (Windows, DOS), but have spent the past 10 years building Java and Python software for other application areas. I've decided to get back into music software, and IPlug / WDL looks like a great way to do that.

Initially, I thought perhaps I could focus on documentation (mostly doxygen-style, with additional howtos on various areas). That would dovetail nicely with my own learning process, as I knock the rust off old skills :) It would also be a good way to get familiar with what everyone's doing. Once I'm back up to speed, I'd love to work on improving MIDI support and whatever. There are lots of MIDI-oriented plugins I'd like to build :D

In addition to code, I've written lots of software docs, some for fairly large systems (2K Java classes), and am comfortable spelunking through large codebases. I've also done some open-source work (Java tooling for Eclipse) a few years back. I plan to get set up with Git, Doxygen and Visual C++ 2010 Express this weekend. (If VS 2008 is a better choice, let me know. I can also use VS 6.0 if necessary, but that seems a bit long in the tooth at this point.)

My time will be somewhat limited (I have a family and a full-time job) but I'm looking forward to contributing where I can.

best,
jim

[bvesco]

@olilarkin

The pr1 and pr2 are just a few branch pointers I made to facilitate easier pull request management. I noticed you haven't merged pull request 2. Do you want to do it? Click the "merge help" on the pull request and follow the instructions there. Also, I don't seem to have permission on the new wdl-ce organization to create a new team for collaborators. Is that something you can do or give me permission to do? Until we add the collaborators to a team on the new project we can't really get the ball rolling over there.

@cubits
@omijim

Sign up as collaborators on the membership wiki page.
https://github.com/audio-plugins/wdl-ce/wiki/Membership

If you want to take on a particular project, documentation or some other improvement, we can get a ticket and branch started for you and you can go to town.

[olilarkin]

i tried but...


olimbp2:wdl-ce oli$ git fetch origin
olimbp2:wdl-ce oli$ git checkout -b fccb3fd origin/fccb3fd
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'origin/fccb3fd' which can not be resolved as commit?
olimbp2:wdl-ce oli$


any ideas? i checkedout pr2

[olilarkin]

i think i merged it ok, but i'm confused because now it says:

Merge branch 'candidate' into fccb3fd

not Merge branch fccb3fd into candidate


here's what i did:



olimbp2:wdl-ce oli$ git checkout -b fccb3fd origin/pr2
Branch fccb3fd set up to track remote branch pr2 from origin.
Switched to a new branch 'fccb3fd'
olimbp2:wdl-ce oli$ git merge candidate
Already up-to-date!
Merge made by recursive.
olimbp2:wdl-ce oli$ git checkout candidate
Switched to branch 'candidate'
olimbp2:wdl-ce oli$ git merge fccb3fd
Updating 356cf12..5e402de
Fast-forward
WDL/eel2/asm-nseel-x64.obj | Bin 0 -> 7282 bytes
WDL/giflib/{authors => AUTHORS} | 0
WDL/giflib/{copying => COPYING} | 0
WDL/giflib/{changelog => ChangeLog} | 0
WDL/giflib/{developers => DEVELOPERS} | 0
WDL/giflib/{readme => README} | 0
WDL/jnetlib/{makefile => Makefile} | 0
WDL/jpeglib/{readme => README} | 0
WDL/swell/swell-wnd.mm | 20 +++++++++-----------
9 files changed, 9 insertions(+), 11 deletions(-)
create mode 100644 WDL/eel2/asm-nseel-x64.obj
rename WDL/giflib/{authors => AUTHORS} (100%)
rename WDL/giflib/{copying => COPYING} (100%)
rename WDL/giflib/{changelog => ChangeLog} (100%)
rename WDL/giflib/{developers => DEVELOPERS} (100%)
rename WDL/giflib/{readme => README} (100%)
rename WDL/jnetlib/{makefile => Makefile} (100%)
rename WDL/jpeglib/{readme => README} (100%)
mode change 100644 => 100755 WDL/swell/mac_resgen.php
olimbp2:wdl-ce oli$ git push origin candidate
Counting objects: 1, done.
Writing objects: 100% (1/1), 233 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:b-vesco/wdl-ce.git
356cf12..5e402de candidate -> candidate

[bvesco]

It's ok, we're using git! I rewound the repo and made it look "normal" again. I also updated the pull requests wiki page with a modified script that should prevent problems with future merges.

I think we're going to have a problem with the "forked" status of the wdl-ce organization. Check out the network graph. It reflects changes in the b-vesco version separately, but as the parent, rather than it looking like I'm a contributor.

I'm going to hit the "growing pains reset button" and set up a new repo to be the parent, so my personal repo will instead let me look like a contributor rather than the owner of everything. Everyone will then fork their own repos off of it.

[bvesco]

Ok, everyone who was interested in being collaborators please go to the https://github.com/audio-plugins/wdl-ce and click the fork button. This will create your personal fork which is where you should do all your work. There are a few new wiki pages set up at the project's new home, of particular interest to collaborators would be the page about "Issues" there.

[olilarkin]

https://github.com/olilarkin/wdl-ce/commits/docs

i added a branch with some basic doxygen html for iplug. Please could those of you who said you were interested in working on docs, check it out at github, and if you approve this initial version please say so on the issue page

https://github.com/audio-plugins/wdl-ce/issues#issue/6

thanks,

oli

[olilarkin]

anyone fed up of using the command line for git on osx, i highly recommend tower:

http://www.git-tower.com/

now i should go to sleep :-)

[omijim]

I have git working now (more or less) and have forked wdl-ce as requested (and also set the main wdl-ce repo as my upstream repo). My local git repo looks plausible :) I've also added an 'approve' comment to the github issue list. (I'd hoped to do a bit more this weekend, but we had a bit of a flood in the basement (heavy rain on a foot of snow == flood, even living on a hillside:()

BTW: comment 33 seems a bit out of date: the membership wiki page is apparently now https://github.com/audio-plugins/wdl-ce/wiki/Membership

[olilarkin]

I signed up :)

Fwiw, the biggest thing I would change is combining IGraphics and IGraphicsLice, removing all of the drawing methods, and simply exposing the lice bitmap to the plugin implementer. When iplug was written, lice did not exist (the original implementation used GDI+, which is why the abstraction between IGraphics and IGraphicsLice exists.).

That change would remove a bunch of pointless pass-through code, and make plugin drawing far more flexible. The coder could just call Lice functions directly.

i had a go at doing what you said...

see https://github.com/olilarkin/wdl-ce/tree/igraphicsmod/WDL/IPlug

would be great if you could cast an eye over it.

were you suggesting that we actually get rid of IGraphics :: DrawCircle etc, and just call _LICE::LICE_Circle() etc directly in the IControl draw methods? If so would you suggest removing the IColor and IChannelBlend structs and just using the lice equivalents?

[schwa]

were you suggesting that we actually get rid of IGraphics :: DrawCircle etc, and just call _LICE::LICE_Circle() etc directly in the IControl draw methods? If so would you suggest removing the IColor and IChannelBlend structs and just using the lice equivalents?

That is what I was suggesting, pretty much. Instead of the plugin calling IGraphics methods to draw primitives, IGraphics would give the plugin direct access to the draw bitmap, and the plugin could use LICE functions to draw/blit on it directly.

[olilarkin]

over at github, we've stalled a bit because of not enough voices...

if you said you wanted to be involved and have a chance this weekend, please could approve/disapprove/comment of this pull request to remove jpg support and tidy up the vs projects...

https://github.com/audio-plugins/wdl-ce/issues#issue/42

thanks!

[olilarkin]

new readme pull request and 64 bit support added. github's notification system seems a bit limited, so i'll post updates about what we're doing here.

as before, comments are very welcome approve/disapprove!

[HoRNet]

i would like to be involved, i made some custom mods to IPlug for my plug

http://www.hor-net.com/plugin/

and incorporated some other changes (don't remember exactly where i got them...)

Anyway i would be interested in having a single maintained tree where i can find everything i need instead of working on my own and having to patch sources every time...

Count me in i will signup on git-hub.

[cc_]

I've signed up but haven't had time to figure out what to do yet!

[olilarkin]

so we now have mac/win 64bit support in the IPlugEffect most-basic-plugin example.

next issues are...

- make some other example projects based on the ones in WDL/IPlug/Example/
- serialization stuff
- merging IGraphicsLice to IGraphics
- get fonts working in a nice cross platform way
- get text entry and menu entry working in a nice cross platform way


RE fonts, In my experiments with Lice Cached font, I still get annoyed that the fonts look different on windows and mac, because it's using the platform font rendering. I suggest we incorporate the Freetype library and load in .ttf files as resources. This way we should get pixel-identical font rendering on mac/win. If anyone has any opinions about that please speak up! The freetype license seems to be compatible.

oli

ps. still wish we had some more contributors... seems to be very quiet around here :-(

[cerberus]

RE fonts, In my experiments with Lice Cached font, I still get annoyed that the fonts look different on windows and mac, because it's using the platform font rendering. I suggest we incorporate the Freetype library and load in .ttf files as resources. This way we should get pixel-identical font rendering on mac/win. If anyone has any opinions about that please speak up! The freetype license seems to be compatible.

yes, please. i know about all of these issues, the blinking of intersecting IText too.


ps. still wish we had some more contributors... seems to be very quiet around here :-(

i'll do my best to stick with it; i think some documentation which is sensitive to
the needs of nøøbs, could catalyse activities here. e.g. there's more than
one "Draw()" method called by controls etc. i had to seek help to even
recongnize that. so how does one become educated about iplug?
(code completion in xcode is not what windows users imagine, btw)

so i hope that documentation could be a top priority.

[Rome]

ps. still wish we had some more contributors... seems to be very quiet around here :-(

I signed up as well.

I'm currently have a lot of work to do in the 'real world' but I'm curious to see if I can get parts of WDL/LICE to work under Linux (GTK+ or maybe even pure X). I believe it can be done, especially since much of the code already is cross platform. :)

RE fonts, In my experiments with Lice Cached font, I still get annoyed that the fonts look different on windows and mac, because it's using the platform font rendering. I suggest we incorporate the Freetype library and load in .ttf files as resources. This way we should get pixel-identical font rendering on mac/win. If anyone has any opinions about that please speak up! The freetype license seems to be compatible.

Freetype would be a great choice as it would remove a huge platform dependency from the code. This may be a good place to start for me. I just have to figure out all that Git stuff first. :)

[olilarkin]

i'll do my best to stick with it; i think some documentation which is sensitive to
the needs of nøøbs, could catalyse activities here. e.g. there's more than
one "Draw()" method called by controls etc. i had to seek help to even
recongnize that. so how does one become educated about iplug?
(code completion in xcode is not what windows users imagine, btw)

so i hope that documentation could be a top priority.


it's hard for sure. Documentation is a priority. actually the basic doxygen that we have added is already quite helpful for understanding the class hierarchies.



I'm currently have a lot of work to do in the 'real world' but I'm curious to see if I can get parts of WDL/LICE to work under Linux (GTK+ or maybe even pure X). I believe it can be done, especially since much of the code already is cross platform. :)

Freetype would be a great choice as it would remove a huge platform dependency from the code. This may be a good place to start for me. I just have to figure out all that Git stuff first. :)

yeah, git can be a bit tricky to understand at first and quite laborious via the command line. Now i am using a graphical frontend, it's much easier.

I am interested in getting some kind of linux support for iplug, but i'm not sure what is the best format to support. Probably lv2, but i don't understand how the gui works. It's not a high priority for me tho.

[HoRNet]

i haven't found the time to try to compile my plug against the IPlug-Ce, i hope to be able to do it in this week...

[Rome]

yeah, git can be a bit tricky to understand at first and quite laborious via the command line. Now i am using a graphical frontend, it's much easier.

I am interested in getting some kind of linux support for iplug, but i'm not sure what is the best format to support. Probably lv2, but i don't understand how the gui works. It's not a high priority for me tho.

I think it is a good idea to leave out Linux plugin formats for now and concentrate on the basics, eg getting basic applications and graphics running first - maybe starting with the jet pack example and building up from there.

[olilarkin]

did you see http://www.1014.org/?article=414

i guess that means that most of wdl is probably linux ready already. certainly, swell seems sometimes to be named "simple windows emulation for linux" (and sometimes "...for losers who use osx")

wdl-ce is more of an iplug-ce at the moment to be honest. iplug doesn't use much of swell, so getting it to run on linux is a different project than building a standalone app, with maybe a little crossover.

[dogby]

Hi,

I am writing a plug. I have made some mods to WDL/IPlug that might be useful to the community. And I have been experimenting with Oli's igraphics text mod for allowing multiple fonts.

Have to admit, I know almost nothing about git and github, and have some very basic questions.

I've got a github account now.

Which repo do I fork ?

Oli's
Vesco's
Audio-plugin-wdl-Ce
?

Why has Oli's repo got 20 branches ? Whilst the other have 3 ?

Which of Oli's 20 branches is the "best" one ?

How would I go about incorporating Oli's igraphicstextmod changes into my repo

Sorry for the very naive questions


dogby

[olilarkin]

Hi,

I am writing a plug. I have made some mods to WDL/IPlug that might be useful to the community. And I have been experimenting with Oli's igraphics text mod for allowing multiple fonts.

Have to admit, I know almost nothing about git and github, and have some very basic questions.

I've got a github account now.

Which repo do I fork ?

Oli's
Vesco's
Audio-plugin-wdl-Ce
?

Why has Oli's repo got 20 branches ? Whilst the other have 3 ?

Which of Oli's 20 branches is the "best" one ?

How would I go about incorporating Oli's igraphicstextmod changes into my repo

Sorry for the very naive questions


dogby



you should fork from audio-plugins wdl-ce, although for the time being, until it stabilises a bit and we make the first "release" I would recommend that people don't move their existing projects to use wdl-ce. but please go ahead fork that one and submit your contributions

there are ~20 branches in my repo because every time i'm adding something i create a work branch based on candidate to fix that particular thing, and when it's ready to go the the main repo I make a pull request. unless its for your own experiments, i wouldn't base your projects on these work branches. If you can wait a little bit i hope i can get the igraphics and text stuff ready to go in the main wdl-ce repo, but still need to work out how to render the fonts with freetype

[olilarkin]

I realised that since people are compiling native vst plugins for linux, the simplest route to adding linux support to iplug would be to support native vst on linux. With a few changes i got the iplugeffect project compiling, but it doesn't load properly in jost ( a linux vst host)

I think it's todo with the plugin entry point in IPlug_include_in_plug_src.h. Any linux gurus fancy giving it a shot?

https://github.com/olilarkin/wdl-ce/tree/basiclinuxsupport

oli

[liteon]

I realised that since people are compiling native vst plugins for linux, the simplest route to adding linux support to iplug would be to support native vst on linux. With a few changes i got the iplugeffect project compiling, but it doesn't load properly in jost ( a linux vst host)

I think it's todo with the plugin entry point in IPlug_include_in_plug_src.h. Any linux gurus fancy giving it a shot?

https://github.com/olilarkin/wdl-ce/tree/basiclinuxsupport

oli

a couple of things:

- while this is viable and recommended:

#define EXPORT __attribute__((visibility("default")))

just give it a try without the attribute (i.e. #define EXPORT)
while the attribute can provide the equivalent to __dllexport, there a couple of downsides:
* not all ELF targets recognize the attribute.
* GCC >= 4

- not sure exactly with what warning levels IPlug is compiled, but in the case of the holos (http://holos.googlecode.com) library (was axonlib) there is no definition of a "main" function at all for shared objects, since it is presumably reserved by the language. with higher warning levels the compiler (e.g. gcc) may account for it - the language specification is strict about the declaration of "main" as:

int main(void);
/* or */
int main(int num_params, char** params);

/* and most definitely not as */
AEffect* main(audioMasterCallback audioMaster);


the work-around for gcc/mingw is to "inject" the "main" symbol (compiler specific naming) at the declaration of an entry-point and then override the definition locally with a macro. this is not exactly a hack / trick, but the equivalent of manually defining the desired symbol in the assembly output:


#if defined __linux__
/* gcc */
#define _ASM_MAIN_SYMBOL asm ("main");
#endif
#if defined __APPLE__
/*
probably "main" as well.
you need to check what naming scheme gcc-apple is using.
*/
#define _ASM_MAIN_SYMBOL asm ("main");
#endif
#if defined _WIN32
/* mingw */
#define _ASM_MAIN_SYMBOL asm ("_main");
#endif

/*
declaration of the entry point here.
notice the symbol definition on the right
*/
AEffect* main_plugin(audioMasterCallback audioMaster) _ASM_MAIN_SYMBOL
#define main main_plugin

/* definition of the entry point */
EXPORT int main(audioMasterCallback hostCallback)
{
return (VstIntPtr) VSTPluginMain(hostCallback);
}



it could be something else entry point related, but also something in the library interface...
jost is not a very pretentious host in general, but try something like energyxt-linux as well. also try running these linux hosts from a terminal and observe the output while loading the library.


cheers
--

[olilarkin]

Thanks very much, I will give those things a try.

On github I have a pull request where I have created msvc and Xcode files for tale's examples and also added in some "place holder" projects for testbed/examples. One of those is a project that would show off all the different iplug controls like vstgui's drawtest. I was hoping that someone might like to take on the task of making that example.

Any volunteers? don't all put your hands up at once!

[cerberus]

could anyone please estimate how close iplug might
be to being able to build vst3 format plug-ins?

[olilarkin]

I think vst3 support is quite a lot of work, not a priority for me.

Do any of you guys who said they'd like to work on documentation fancy fixing the example projects as I mentioned above? Would be a good way to learn iplug and good examples are the best form of documentation IMO

Would really like to assign some tasks so I can get on with other things(text etc)

[markheath]

I've signed up, looks an interesting project. Do you have a roadmap / list of desired features somewhere?

I've mainly been doing .NET audio apps in recent years, but I can do C/C++ too, and maybe I'll be able to contribute something.

[olilarkin]

The best list is at the top of this thread. A roadmap is a good idea, but at the moment it seems like no one else has any time to contribute to this project. Until we get some more devs who are really committed to it, I don't know if it can work

[captain caveman]

Is it something based along these lines you want for the GUI example?....

http://stash.reaper.fm/oldsb/1109861/IControlExampleGUI_001.png

... I haven't seen the VSTGUI example so I don't know what to aim for.

[olilarkin]

yep exactly

[captain caveman]

yep exactly
Cool, leave it with me. I'm glad I can be of assistance to the project! :)

[olilarkin]

great, thanks...if you have any questions about how to use the controls I can probably help, i've used most of them now. Also It would be good to use some nice-looking knob/slider gfx. I have some we could use http://olilarkin.blogspot.com/2011/03/povray-knobs.html

If someone is interested in writing an "iplug getting started" pdf/html tutorial that would be very useful

[captain caveman]

I was going for more of a technical sort of demo where I have a couple of controls for some of them showing the effect of the different parameters and target areas shown etc. Here is the Skinman image so far with the multi control images all completed (single buttons in this image for the RadioButtons for obvious reasons). I've coded and tested down to the IContactControl so far.

http://stash.reaper.fm/oldsb/1110857/IControlExampleGUI_002.png

I sort of like the minimalist look, but if you guys want more standard controls then it won't be much hassle to change them.

[olilarkin]

minimal is fine... looking good

[captain caveman]

Thanks, I'll probably take you up on the offer of help when it gets to the third column too!! :)

Oh, and is there an example of IKnobRotatingMaskControl out there so I can see what it does? It'd save me having to put together random images etc to test.

[cerberus]

i find that PromptUserInput perhaps could be broken in wdl-ce for windows xp platform...

(tested with reaper3.x). the text box opens, but it won't accept a user input. works fine on osx.
this could be a bug in my own code... can anyone verify that PromptUserInput does work properly
on all platforms with wdl-ce ? i also notice that /*on windows and osx audio units, that the
text box is larger than with cockos wdl, and it is offset to the right slightly (not centered
anymore) and it */ audio units lacks the highlighted outer border "focus ring".

[olilarkin]

Captain caveman - Actually I haven't tried that control- not sure how it works!

Cereberus- there may well be some problems with ipromptuserinput. In my personal repo I have got windows and osx cocoa almost identical but osx carbon still has a blue ring that is larger than the text entry area. Going to submit these changes to wdl ce soon.

[cerberus]

hey oli, fyi: here is how it looks in cubase (vst, osx):
http://cerberusaudio.com/a/Screen%20shot%202011-05-09%20at%2019.41.24%20.png

i think the focus ring is there actually, but hard to see..

in reaper (osx, audio units):
http://cerberusaudio.com/a/Screen%20shot%202011-05-09%20at%2019.45.54%20.png

the focus ring is not there, but it still works.

windows/reaper (xp, vst) appears like this:
http://cerberusaudio.com/a/Screen%20shot%202011-05-09%20at%2019.55.01%20.png

here, the user input does not take.

thanks for your continuing work on this.

[cerberus]

hrm, i wouldn't be knowing much at all about win_api...
may i please mindmeld with your personal repo and
assimilate the fixed PromptUserInput() ?

[olilarkin]

you might find what you want here: http://www.olilarkin.co.uk/dev/WDL.git/ I think the version there has that stuff

[cerberus]

ty oli!

[olilarkin]

been doing some work on the examples branch. added resampler example and got most of the msvc and codeblocks projects compiling. still need to implement one for chunks, multichannel stuff, pitchshifter... and add in the controls one that captin caveman is working on

the idea of these as well as documenting, is to provide a testbed to evaluate all the wdl-ce mods against.

[sstillwell]

Okay, which one's the "official" site/repo for wdl-ce now?

Scott

[olilarkin]

https://github.com/audio-plugins/wdl-ce/

[captain caveman]

Sorry about the delay, my laptop broke so I'm back up and running now.

That's it nearly complete apart from a couple of issues....

http://stash.reaper.fm/v/8644/IControlExample.dll*

The IRotatingMaskControl has me confused, you can see the component images in the background image but the assembled control doesn't do much even thought the images are in the right place. Here it is...

IBitmap base = pGraphics->LoadIBitmap(IKRMC_BASE_ID, IKRMC_BASE_FN);
IBitmap mask = pGraphics->LoadIBitmap(IKRMC_MASK_ID, IKRMC_MASK_FN);
IBitmap top = pGraphics->LoadIBitmap(IKRMC_TOP_ID, IKRMC_TOP_FN);
pGraphics->AttachControl(new IKnobRotatingMaskControl(this, kIKRMC_X, kIKRMC_Y, kIKnobRotatingMaskControl, &base, &mask, &top));

I am not sure what ICaptionControl is supposed to do either. I tried to link it in OnParamChange to another parameter, but no dice. I could do with a nudge in the right direction for that one.

Finally, the IFileSelectorControl is probably one that a more capable IPlugger should do. ;)

edit: *plugin updated as per Tale's post below.

[Tale]

The IRotatingMaskControl has me confused, you can see the component images in the background image but the assembled control doesn't do much even thought the images are in the right place.
I think that is because the default value of 0.75 * PI for minAngle and maxAngle seems to be in radians, but I think the angles should be specified in degrees, so 0.75 * 180 = 135 would be a better default value. If you add more correct values to your example, then you should at least be able to move the control:

pGraphics->AttachControl(new IKnobRotatingMaskControl(this, kIKRMC_X, kIKRMC_Y, kIKnobRotatingMaskControl, &base, &mask, &top, -135., 135.));

[captain caveman]

Yes, that was it Tale - thanks. I've updated the file in the stash the link above goes to and added a comment in the code next to that control. The graphics for it still aren't exactly what the component images to the left should stack up to though. Maybe the mask has to be a certain colour, but that still probably wouldn't explain why the cross hair top section turns into an outline.

Looking at the rotation of it too, it appears to exhibit the same wobbling and fuzzy sides that IKnobRotaterControl shows. I have noticed whilst doing my plugins that even the yOffsetZeroDeg doesn't correct a wobbly knob and the surrounds aren't as defined as when a multi-image is used with IKnobMultiControl. I have tried images with dimensions of odd and even numbers of pixels but can't seem to tame that control.

That's possibly one for another time, but I don't want to leave this control looking the way it does.

[olilarkin]

i tried it captain. seems good. i noticed as well as the fuzzyness maybe the rotation is slightly off in IKnobRotatorControl. Maybe your knob graphic is not totally centred?

re the fuzzyness, there is something wrong with IGraphicsLice:: DrawRotatedBitmap() or the lice function it calls.

re ICaptionControl, usually you would use this to display the value of a slider or knob. At the moment one of the issues that we need to address in wdl-ce is the way that multiple controls linked to the same parameter update each other. I haven't actually used ICaptionControl myself for the readout displays in my plugins... I just made one control that has a text display/editing area. Probably for the IPlugControlsDemo you could add another control to the ICaptionControl area and in OnParamChange() set the ICaptionControl dirty when the parameter value changes.

so are you going to push the source to the examples branch on github? i can add in the missing controls if you like

[captain caveman]

Yes, that would be good. I have wrestled with GitHub previously and didn't "get it" so instead of wasting time and potentially destroying the wdl-CE project it'd probably be better if I just linked to a .zip package...

http://jof.org.uk/Share/IControlExample.zip

Much obliged. :

[Cubits]

I will be making contributions soon just been busy with a few things still got to get my head round GIT aswell lol

[olilarkin]

i have added the code to the examples branch. still cant get it working on codeblocks though

[HoRNet]

ok i've started working on the new version of my channelstrip and linking against wdl-ce.

i had to add a method to IControl that i'll be going to submit for review once i'm happy, but i've found a problem with the ICaptionControl with Cocoa hosts such as Reaper on OSX.

I have a IKnobMultiControl and an ICaptionControl bound to the same parameter index, now on Live 7 (a carbon host) i can edit the iCaptionControl and the IKnobMultiControl is updated accordingly, on Reaper (Cocoa) the input from the ICaptionControl is ignored. I've run the debug and found where the problem is, but my Objective-C is really not up to the task...



- (void) controlTextDidEndEditing: (NSNotification*) aNotification
{
//char* txt = (char*)[[mParamEditView stringValue] UTF8String];

NSInteger vi = -1;
if ([mParamEditView respondsToSelector: @selector(indexOfSelectedItem)] == YES)
vi = (NSInteger)[mParamEditView indexOfSelectedItem];
if (vi != -1)
mEdControl->SetValueFromUserInput(mEdParam->GetNormalized((double)vi));
//else
//mGraphics->SetFromStringAfterPrompt(mEdControl, mEdParam, txt);

EndUserInput(self);
[self setNeedsDisplay: YES];
}



in this method from IGraphicsCocoa.mm vi is always -1 since the check for the message respond fail. The problem is that i don't know why it fails, that's where my Objective-C ends...

any help?

[Tale]

The problem is that the code to handle "raw" text input (i.e. not from a drop-down list) is commented out. In my Git repository this handled by IGraphics::SetFromStringAfterPrompt(), but the current wdl-ce repository doesn't have such a method.

I guess you could hack the missing code into the current wdl-ce code like this:

- (void) controlTextDidEndEditing: (NSNotification*) aNotification
{
char* txt = (char*)[[mParamEditView stringValue] UTF8String];

NSInteger vi = -1;
if ([mParamEditView respondsToSelector: @selector(indexOfSelectedItem)] == YES)
vi = (NSInteger)[mParamEditView indexOfSelectedItem];
if (vi != -1)
mEdControl->SetValueFromUserInput(mEdParam->GetNormalized((double)vi));
else
{
double v = atof(txt);
if (mEdParam->DisplayIsNegated()) v = -v;
mEdControl->SetValueFromUserInput(pParam->GetNormalized(v));
}

EndUserInput(self);
[self setNeedsDisplay: YES];
}

[olilarkin]

yes it's commented out because i have done a lot of work on this stuff, and implemented the text entry / menu stuff a bit differently. just need to find the time to add it to wdl-ce.

[HoRNet]

Thank you Tale, what you wrote makes a lot of sense :) and in fact works fine.

There is still a problem, the ICaptionControl is updated and the param takes the new value, but the knob is not redrawn to te new value. In Carbon hosts this works fine and the knob is updated, so i fired the debugger and had a look line by line to the carbon code. but i don't see anything special the drawing is made with this code


if (mIsComposited)
{
//IRECT* pR = mEdControl->GetRECT();
//HIViewSetNeedsDisplayInRect(mView, &CGRectMake(pR->L, pR->T, pR->W(), pR->H()), true);
HIViewSetNeedsDisplay(mView, true);
}
else
{
mEdControl->SetDirty(false);
mEdControl->Redraw();
}



now Live is a composited host so the only code that is called is
HIViewSetNeedsDisplay(mView, true);

that i think is the Carbon equivalent for the Cocoa
[self setNeedsDisplay: YES];

but the Carbon ui is updated, the Cocoa one no, am I missing something?

[HoRNet]

sorry guys, forget my last message, it's not a Cocoa / Carbon issue.

I was testing with Live that after setting a parameter from the plugin informing the host, it sends back the updated value to the plugin, this updates my knob control.

I tested the plugin with an old copy of Tracktion (Carbon) and the knob is not updating, because just like Reaper it doesn't sends the value back to my plugin

[cerberus]

windows... ...the user input does not take.

a solution for this (if you are using wdl-ce) is to change line 688 in IGraphicsWin.cpp (IGraphicsWin::CreateTextEntry) from:
mParamEditWnd = CreateWindow("EDIT", pString, WS_CHILD | WS_VISIBLE | editStyle ,
to:
mParamEditWnd = CreateWindow("EDIT", pString, WS_CHILD | WS_VISIBLE | ES_MULTILINE|editStyle ,

also, the text box has it's own mousewheel response... it could be a nice feature, but i found
the behavior confused me at first. it can be disabled by commenting out:

IGraphicsWin.cpp line 207 pGraphics->mParamEditMsg = kCancel;
IGraphicsCocoa.mm line 242 if(mTextFieldView) [self endUserInput ];
IGraphicsCarbon.cpp line 178 if (_this->mTextFieldView) _this->EndUserInput(false);

special thanks to ArdeII for these!
imo, everyone should try Kirnu (his cool, friendly, and free arpeggiator plug-in)
and submit their wildest feature requests for a future version :-)

[Tale]

i had a go at doing what you said...

see https://github.com/olilarkin/wdl-ce/tree/igraphicsmod/WDL/IPlug
I have also had a go at this, and I have now succesfully removed IGraphicsLice from my WDL/IPlug repository. I have split up the changes in 3 seperate commits:

ddb596c IPlug: Merged IGraphicsLice into IGraphics.
e67a0f8 IPlug: Removed IGraphicsLice from project files.
0bf285c IPlugExample.xcodeproj: Removed IGraphicsLice.

I have tried to keep things as clean as possible, so regardless of which WDL/IPlug your are following you should be able to cherry-pick the first commit, which contains the bulk of the changes. You could skip the other 2 commits, provided that you remove IGraphicsLice.h and IGraphicsLice.cpp from your project files yourself.

BTW, it seems that these changes have quite an impact on file size: The Windows DLL for my ComboV project is now almost 100 kB smaller, and the Mac OS X VST is about 300 kB smaller.

[olilarkin]

anyone still interested in wdl-ce? I am pretty tired of doing 95% of the work - and I am starting to think I should just focus on my own repo.

If anyone fancy's doing some work on it, I would suggest a good next step would be to look at bringing it Tale's font and IGraphics mods.

The examples that i have been working on are nearly ready to be merged to the main branch i think, but need a little bit more work.

oli

[junioreq]

Sorry I cannot contribute. Would REALLY love to, but I'm still in newbie status with Obj coding. Believe me though, your efforts are well noted and I and some other folks do check your updates regularly.

I thought this would take off a bit more, but as I don't contribute, I probably shouldn't comment on that. It's not totally relevant to your post again, but I want to thank you publicly for what you have done.

[cerberus]

my plug-in is near release. i couldn't have had the features i wanted without
wdl-ce, such as the text entry, which is working properly on both windows
and osx thanks to your efforts. i'm new to coding, so the best i can offer
to the community and to cockos is the plug-in itself. it will be for sale,
but anyone who contributed to wdl-ce, and probably reaper users
as well may have it for free (still in beta at the moment), i want
to say how much i appreciate your help too, oli!

http://cerberusaudio.com/a/WDLCErocks.png

[HoRNet]

I've completed som mods to the WDL for my own plugin ho can i contribute them to the project? how the review is done?

[bvesco]

Did you fork from the WDL-CE repo on github?

[HoRNet]

yes, but it was some time ago, i don't think i'm current, better merge a new wdl-ce in my repo before pushing my changes to git hub? (actually i hav them only on my local hard drive)

[olilarkin]

I think you need to fork wdlce on github, check out that repo to your local machine , add your changes, then push them to your github and make a pull request to merge back to wdlce

[HoRNet]

ok i think i'll update my repo and do a pull request, but i cannot guarantee anything, never done that before (i use git for all my projects, but neve rused in a collaborative manner, so i don't know how to do a pull request :))

[bvesco]

The pull request thing is pretty simple after you're used to it. It can be confusing the first time you do it. Maybe we can get on chat sometime when you're ready to do it.