PDA

View Full Version : WDL in the wild


schwa
08-17-2010, 09:37 PM
As of 8/16/2010, Cockos WDL (http://www.cockos.com/wdl/) is available as a Git repository.

If you are a WDL user, you can clone the Cockos repository to create your own working copy of the code. When Cockos WDL is updated, you can use Git to selectively choose to merge in any or all changes that you want to incorporate into your own code.

If you are a WDL user and you use Git for your own source code control, you can add the Cockos WDL repository as a remote, following Justin's instructions here. (http://forum.cockos.com/showpost.php?p=567676&postcount=12) This will let you manage your own code, and also selectively merge in changes from Cockos WDL.

Here's where it gets interesting: if you are a WDL user and you have improved WDL with local modifications, please feel free to host your own repository of WDL (or IPlug or any submodule of WDL)! You can use GitHub (https://github.com/), Google Code (http://code.google.com/), any other public source code repository service*, or your own personal server. If any group of WDL users wants to create a shared repository, that's fine too.**

The Git vision is that everyone who has something to add to WDL (including Cockos) will host their own repository, and everyone who uses WDL (including Cockos) will, over time, add the repositories of trusted coders as a remote. That way we can all look at each others' improvements, and pull any changes we like into our own code.

So, have at it! WDL is officially in the wild. We look forward to seeing what happens!


* Please make sure to read and understand the license terms of any commercial source code repository service.

** The Git vision is that there is no centralization, and therefore no politics about who is trusted to change the code and who isn't. Shared repositories can be good if they increase the trustability of that particular location, but bad if they exclude valuable contributors from becoming known.

Tale
08-19-2010, 07:50 AM
I have followed Justin's instructions, and added WDL as a remote. After that I have created a new branch (tale), in which I have committed a couple of changes. I have uploaded the updated repository to my own webserver:

http://www.taletn.com/WDL.git

Could someone with a little more Git experience than me please check if this works? I can clone my own repository, so it does seem to work.

schwa
08-19-2010, 10:36 AM
Looks good!


$ git remote add tale_wdl http://www.taletn.com/WDL.git

$ git branch -r | grep tale
tale_wdl/master
tale_wdl/tale

$ git log -n 1 tale_wdl/tale
commit c9a55cfe46fd0616c64108ff01f428519ca110c1
Author: tale
Date: Thu Aug 19 16:11:36 2010 +0200

Fix a couple of typos / small bugs.

Tale
08-19-2010, 12:15 PM
Cool, thanks!

I have just updated my repository with all my modifications. I guess now would be a good time for me to check if they actually compile and work after migrating them to Git. :D

Justin
08-19-2010, 03:25 PM
I'm having trouble reading it... Perhaps you need to rename the file:

http://www.taletn.com/WDL.git/hooks/post-update.sample

to

http://www.taletn.com/WDL.git/hooks/post-update

(and chmod +x it) ?

(and manually run git-update-server-info too)

Tale
08-19-2010, 03:53 PM
Ok, I see. I already thought this was going too easy... I have simply uploaded the WDL.git bare repository folder to my webserver, but I haven't actually installed Git on that server. I guess I really need to have Git installed there, right?

schwa
08-19-2010, 04:16 PM
I was able to read your repository fine earlier, but not any more.

[edit] if you just copy the repository to the server, I think people can read it (not sure), but if you want to make your server repository a working bare repository that you can actually push changes to (much more useful :)), you do need git on the server.

RRokkenAudio
08-19-2010, 04:24 PM
I read it fine, right after schwa initially did. Just tried, read fine.

http://gyazo.com/48956522fc4e778812919c997ed4a304.png

~Rob.

Justin
08-19-2010, 06:29 PM
Hmm it might not be git-update-server-info.. not sure what is going on there, I can clone sometimes, but can't fetch, too.. something awry...

Tale
08-20-2010, 02:17 AM
I did do "git update-server-info" locally, before I uploaded, but I am not sure if that is good enough.

if you just copy the repository to the server, I think people can read it (not sure)
Apparently not, I guess, although I don't (yet) understand why.

but if you want to make your server repository a working bare repository that you can actually push changes to (much more useful :)), you do need git on the server.
This is probably also safer, because now I have to swap the updated and outdated repository each time I upload it, so for a very short moment during the swap it is unavailable. I assume Git would take care this if I push changes.

Anyway, I think I will have to either install Git on my webserver, or move things over to a Git hosting website.

Justin
08-20-2010, 08:24 AM
I did do "git update-server-info" locally, before I uploaded, but I am not sure if that is good enough.


Apparently not, I guess, although I don't (yet) understand why.


This is probably also safer, because now I have to swap the updated and outdated repository each time I upload it, so for a very short moment during the swap it is unavailable. I assume Git would take care this if I push changes.

Anyway, I think I will have to either install Git on my webserver, or move things over to a Git hosting website.

Yeah, or maybe run git update-server-info locally and rsync -- if it is invalid for a moment then anybody fetching at that time can refetch I'm sure. Depending on your web server's distribution, installing git can be pretty trivial (sudo apt-get install git-core).

Tale
08-20-2010, 12:05 PM
I think I have found the problem. I had originally "imported" (cloned) WDL into my master branch. Then I created my own branch in which I committed a bunch of changes. Without merging this branch into the master branch, I then "exported" (cloned) my WDL version to my website. Wrong?

I have now merged my branch into the master branch. Hopefully things will now work as expected.

schwa
08-20-2010, 12:43 PM
rrokken, what's that interface?

RRokkenAudio
08-20-2010, 01:11 PM
That would be Smart Git 1.5 sir....

~Rob.

schwa
08-20-2010, 04:59 PM
Tale, I'm looking through your mods, great stuff!

Tale
08-21-2010, 04:23 AM
Thanks! :) The original isn't that bad either. :p

cc_
08-22-2010, 10:26 AM
I just spent all day gitting and committing.

All my IPlug additions are now here:

http://evenharmonic.com/WDL.git

well, if it worked that is, typing this:

git clone http://evenharmonic.com/WDL.git

makes a directory called WDL with a .git inside, which is not quite the same as I get from the cockos one.

Anyway I am now going to drink beer.

Tale
08-22-2010, 12:35 PM
Cool!

well, if it worked that is, typing this:

git clone http://evenharmonic.com/WDL.git

makes a directory called WDL with a .git inside, which is not quite the same as I get from the cockos one.
Your repository seems to work just fine, and 100% like The Cockos One. BTW, I learned from Schwa that you can add a "." to have Git clone in the current directory (so you get .git and WDL instead of WDL/.git and WDL/WDL):

git clone http://evenharmonic.com/WDL.git .

Anyway I am now going to drink beer.
You sure deserve it after all that Git. :D

Justin
08-22-2010, 03:50 PM
Cool, cc_ and Tale! Both trees look pretty good -- I noticed though that there is some duplicated work (that causes conflicts). Would one of you (or both of you) like to go merge eachothers work, and then I can pull that merged to our tree?

Justin
08-22-2010, 06:02 PM
OK, I've merged tale's branch into our WDL's "next" branch, along with a few other small updates. cc_, your changes look good, but there was some conflict with tale's (relating to right click UI stuff I think), and on OS X at least things I compiled crashed (if you would like a crash report, let me know).. If you want to merge our next branch to yours, that might be good...

-Justin

cc_
08-23-2010, 12:14 AM
Yes, send the crash log! I only switched to the latest WDL yesterday. so maybe there's a problem there.

I took a look at tale's right click code. It's probably cleaner than mine, so I'll take that.

But the main conflict is the whole of the OSX prompt handling stuff, I started it, oli took mine and modded it, tale took oli's and modded it then I took bits of tales and added it back into mine! Mine does more than tale's (Combo boxes, editable text field), so I couldn't use his stuff directly.

I'm not sure the best way forward from here.

Tale
08-23-2010, 03:02 AM
But the main conflict is the whole of the OSX prompt handling stuff, I started it, oli took mine and modded it, tale took oli's and modded it then I took bits of tales and added it back into mine! Mine does more than tale's (Combo boxes, editable text field), so I couldn't use his stuff directly.
I have added the combo box to my Carbon code just before I switched to Git, so it should be in there now. No editable text field though.

I'm not sure the best way forward from here.
Well, I guess could merge my branch with WDL's "next" branch, and then try to merge your editable text field code into it.

cc_
08-23-2010, 03:13 AM
If you have the Combobox working for all cases then I'm happy to try and merge the Editable text field in.

Then I can bin my code and any problems are your fault :)

cc_
08-23-2010, 03:21 AM
Oh yeah, the other thing that I didn't like about your code (last time I looked) is you have duplicated code at the end of the edit in Cocoa, Carbon and Win that could be in IGraphics.cpp . I have the function IGraphics::SetFromStringAfterPrompt(char *txt) to do that stuff. Actually, I guess that's the code that ended up in your Carbon and Cocoa code.

Maybe there some duplication in Carbon and Cocoa that could have been in IGraphicsMac too, I can't remember.

Tale
08-23-2010, 03:32 AM
OK, I've merged tale's branch into our WDL's "next" branch, along with a few other small updates.
I noticed that you have merged all of my changes, which fine by me. But I should perhaps warn you about a couple of changes, because they may break compatibility with existing projects:

8da3756 When state chunks are enabled, use SerializeState() for a patch, and SerializePresets() for a bank.
Before this change SerializeState() was called for both patches and banks.

178c4fe Drop JPEG support.
I have completely dropped JPEG support in IPlug, because I only use PNG images.

964e261 Customized Xcode project file
Although I have added some useful stuff (macro defines), I have also dropped a bunch of code I don't need (e.g. JPEG stuff), but which others may need.

Tale
08-23-2010, 03:54 AM
Oh yeah, the other thing that I didn't like about your code (last time I looked) is you have duplicated code at the end of the edit in Cocoa, Carbon and Win that could be in IGraphics.cpp . I have the function IGraphics::SetFromStringAfterPrompt(char *txt) to do that stuff. Actually, I guess that's the code that ended up in your Carbon and Cocoa code.
Actually there is a lot of duplicate code in the IGraphicsWin.cpp, IGraphicsCarbon.cpp, and IGraphicsCocoa.mm. This could use some cleaning up (move duplicate defines over to IGraphics.h, move some member variables to IGraphics, perhaps even move some code to IGraphics and add a couple of pure virtual methods). However, my original goal was to let the Windows version be, and to make the Carbon and Cocoa verions as much like the Windows version as possible.

cc_
08-23-2010, 04:17 AM
Yes, I figured that's why you did it. I guess that cleaning needs doing before I try adding the editable text otherwise I'll just be making more stuff to clean up later.

Justin
08-23-2010, 10:21 AM
Sorry if I got overzealous.

I noticed that you have merged all of my changes, which fine by me. But I should perhaps warn you about a couple of changes, because they may break compatibility with existing projects:

8da3756 When state chunks are enabled, use SerializeState() for a patch, and SerializePresets() for a bank.
Before this change SerializeState() was called for both patches and banks.



Yeah, on this maybe there should be a default implementation of () that just calls SerializeState()?



178c4fe Drop JPEG support.
I have completely dropped JPEG support in IPlug, because I only use PNG images.



Yeah, I sort of figured "who uses JPG?" .. maybe it makes sense to have two projects with varying levels of inclusion. Or include the jpeglib files and have them unused and let the linker do the work.



964e261 Customized Xcode project file
Although I have added some useful stuff (macro defines), I have also dropped a bunch of code I don't need (e.g. JPEG stuff), but which others may need.

This is why I included those updates, mostly -- the VST_FORCE_DEPRECATED definitions, etc..

Anyway, I guess I'll do some customization for our tree relating to the JPEG support.

Edit: OK, I've updated our next tree with JPEG support returned, but keeping the other project edits. So now we just need to find a good backwards compatible way of handling SerializePresets() and we should be good, eh?

Tale
08-23-2010, 01:09 PM
Sorry if I got overzealous.
:D

Yeah, on this maybe there should be a default implementation of () that just calls SerializeState()?
Edit: OK, I've updated our next tree with JPEG support returned, but keeping the other project edits. So now we just need to find a good backwards compatible way of handling SerializePresets() and we should be good, eh?
Right. I don't think SerializePresets() is used anywhere else, so it is tempting to simply change it to:

bool IPlugBase::SerializePresets(ByteChunk* pChunk) { return SerializeState(pChunk); }

However, this could still break compatibility with an existing project if it happens to call SerializePresets() internally. So I guess it would be better to leave SerializePresets() be (and make it non-virtual again), and add a new virtual method instead, and call that new method for effGetChunk.

EDIT: Tried it here locally, it seems to work. Now I have to figure out how to pull the Cockos WDL's next branch without messing up my own master branch. And then what? Should I publish my own next branch, so you guys at Cockos can pull it, or can I push things to you?

Justin
08-23-2010, 02:17 PM
:D



Right. I don't think SerializePresets() is used anywhere else, so it is tempting to simply change it to:

bool IPlugBase::SerializePresets(ByteChunk* pChunk) { return SerializeState(pChunk); }

However, this could still break compatibility with an existing project if it happens to call SerializePresets() internally. So I guess it would be better to leave SerializePresets() be (and make it non-virtual again), and add a new virtual method instead, and call that new method for effGetChunk.

EDIT: Tried it here locally, it seems to work. Now I have to figure out how to pull the Cockos WDL's next branch without messing up my own master branch. And then what? Should I publish my own next branch, so you guys at Cockos can pull it, or can I push things to you?

You can fetch our stuff (assuming we're a remote called "cockos"), then look at our logs (git log cockos/next). Once you have that, you can merge our branch in, or cherry-pick our edits. I'll keep an eye on your branch and see if there's stuff that makes sense to merge in.

I've just updated ours with support for defining IPLUG_NO_JPEG_SUPPORT, which prevents IPlug from loading JPEGs (which should also cause the linker to throw away all the JPEG related code on link, hopefully).

Tale
08-23-2010, 03:34 PM
You can fetch our stuff (assuming we're a remote called "cockos"), then look at our logs (git log cockos/next). Once you have that, you can merge our branch in, or cherry-pick our edits. I'll keep an eye on your branch and see if there's stuff that makes sense to merge in.
Ok, I think I get it. Thanks.

EDIT: I have fetched the Cockos next branch, made a few changes (SerializePresets, Win SDK 7 makefile), and cloned it to my website (also in a next branch). BTW, you certainly will not want to merge in my "567d9fe Added IPLUG_NO_JPEG_SUPPORT to IPlug Xcode project". ;)

I've just updated ours with support for defining IPLUG_NO_JPEG_SUPPORT, which prevents IPlug from loading JPEGs (which should also cause the linker to throw away all the JPEG related code on link, hopefully).
Yeah, that will work for sure. I like! :)

cc_
08-24-2010, 12:47 AM
Tale, do you plan to clean up the duplicate code in the user input any time soon? For the editable text control the only bit that matters is in PromptUserInput() - just move the common code into IGraphicsMac.mm like I did in my version below. I guess this code could actually be in IGraphics.cpp and used by the windows version too, but that would be a bigger change.

This has all happened at the worst possible time for me, as your code is now in wdl I want to use that, but for me the editable text control is not optional (without it users can't download their licenses!). Meanwhile I'm gearing up to release my first paid for IPlug based plugin, and have all the beta testers lined up waiting!


void IGraphicsMac::PromptUserInput(IControl* pControl, IParam* pParam,bool editableText)
{
if (mEdControl) { // paranoia
if (pControl != mEdControl) {
if (mGraphicsCocoa)
[((IGRAPHICS_COCOA*)mGraphicsCocoa) EndUserEdit];
else if (mGraphicsCarbon)
mGraphicsCarbon->EndUserEdit();
}
else {
return;
}
}

if (!pControl || (!pParam && !editableText)) {
return;
}

IRECT* pR = pControl->GetRECT();
IRECT r(pR->L,pR->T,pR->R,pR->B);

int yAdj = 0;
bool editable=true;
bool secure=false;
const char *currentStr;
char buf[MAX_PARAM_LEN];

int n = 0;
if (editableText) {
currentStr = ((IEditableTextControl *)pControl)->GetText();
editable = ((IEditableTextControl *)pControl)->IsEditable();
secure = ((IEditableTextControl *)pControl)->IsSecure();
}
else {
pParam->GetDisplayForHost(buf);
currentStr = buf;
n = pParam->GetNDisplayTexts();
r.T = MAX(0,r.T - 3);
r.B = r.T + PARAM_EDIT_H + 6;
r.R = r.L + PARAM_EDIT_W;
if (n) {
// calculate combo box width
int w = PARAM_LIST_MIN_W;
for (int i = 0; i < n; ++i) {
const char* str = pParam->GetDisplayText(i);
w = MAX(w, PARAM_LIST_MIN_W + strlen(str) * PARAM_LIST_W_PER_CHAR);
}
r.R = r.L + w;
}
}

if (mGraphicsCocoa) {
[((IGRAPHICS_COCOA*)mGraphicsCocoa) MakeInputPrompt:&r
p:pParam s:currentStr ed:editable sec:secure];
}
else if (mGraphicsCarbon) {
mGraphicsCarbon->MakeInputPrompt(&r,pParam,currentStr,editable,secure);
}
mEdControl = pControl;
mEdParam = pParam;
}

Tale
08-24-2010, 03:23 AM
Tale, do you plan to clean up the duplicate code in the user input any time soon? For the editable text control the only bit that matters is in PromptUserInput() - just move the common code into IGraphicsMac.mm like I did in my version below. I guess this code could actually be in IGraphics.cpp and used by the windows version too, but that would be a bigger change.
Actually I have the afternoon free (it's my sister's birthday), so I have some spare time. I will clean things up, the Windows version as well, and then push it to my public repository, so you can pull the changes from there. I will let you know when I am ready.

cc_
08-24-2010, 04:01 AM
Great!

And Happy Birthday to your sister!

l0calh05t
08-24-2010, 05:01 AM
Seriously... did you have to choose git? It's so awkward.

Anyways, a few small suggestions (since I haven't really figured out the whole GIT thingy yet...):

1. How about switching to CMake? this would make sure added files only need to be added once into the CMakeLists.txt and not for each project file individually -> less management effort. It would also make configuration of builds without specific parts (like jpeg support) much easier, and you compilation time would be reduced by not even compiling in the support, instead of letting the linker do it. Locally I have been using CMake for a few weeks now, and switching to VS2010 only involved running cmake again (same for 64 bit). By using find_package, it would also be easier to use custom builds of libpng (for example using the current release) easier.

2. I would change the IPlugBase constructor to make it NDEBUG compatible (move strstr out of assert). This shaves off ~200kb for each plugin for me.

3. Add license/copyright info to every IPlug file. This was already mostly done for WDL, but not IPlug.

EDIT: Ok, after figuring out how to get the next branch, I see that 2. was already done. So I wasn't the only one to run into that problem.

cc_
08-24-2010, 07:11 AM
Actually I have the afternoon free (it's my sister's birthday), so I have some spare time. I will clean things up, the Windows version as well, and then push it to my public repository, so you can pull the changes from there. I will let you know when I am ready.

Another thing... if while you're at it you can think of a cleaner way to add the editable text stuff, let me know. The way I have at the moment is kind of nasty.

Tale
08-24-2010, 08:26 AM
Another thing... if while you're at it you can think of a cleaner way to add the editable text stuff, let me know. The way I have at the moment is kind of nasty.
I had somehow already forgotten that cleaning up the duplicate code and member variables means object hell. IGraphicsCocoa and IGraphicsCarbon aren't children of IGraphics, so if you move all duplicate member variables to IGraphics, you can't reach them from IGraphicsCocoa and IGraphicsCarbon. And even when you can, your code becomes almost unreadable because of all the pointer overrides. So I am cleaning up only tiny bits of duplicate stuff.

Meanwhile, because I got stuck with cleaning up anyway, I am manually merging in your IEditableTextControl into my next branch.

cc_
08-24-2010, 08:33 AM
Heh, I was hoping that was going to happen :D

And yes I had forgotten that object hell too, but now I remember why I only combined as far as IGraphicsMac!

Tale
08-24-2010, 02:20 PM
I have finished manually merging in cc_'s IEditableTextControl.

Added features:

+ Call DisablePrompt() to disable input.
+ The edit box uses the alignment, font, font size (and on Windows font style) of the text control.

Known issues:

* [Windows] You cannot type beyond the width of the edit box.
* [Mac OS X] Bold and italic font styles are not supported.
* [Carbon] When the text box is read-only you can't select the text nor copy it.
* [Cocoa] Because the text box follows the control's size, the control needs to be relatively high.

You can fetch this from the "next" branch of my repository, along with a few other, minor changes.

cc_
08-24-2010, 11:49 PM
You're star! Have grabbed it...

cc_
08-25-2010, 03:43 AM
I have it all merged with my code and working - looks good!

The only problem I found was that the IText control seems to only display a single line on the Mac. In windows, my Mac one and IIRC the original IPlug Mac one it can display multiple lines.

Tale
08-25-2010, 04:36 AM
Well, I have only added your GetText() method and a new GetIText() method to ITextControl, so I don't know... ITextControl:: Draw() simply calls pGraphics->DrawIText(), so I guess the GraphicsMac:: DrawIText() is the one to blame on the Mac. I haven't made any changes to that medthod, so perhaps that is the problem?

cc_
08-25-2010, 04:55 AM
Yeah, I couldn't see anything you had changed. I'll take a look DrawIText.

l0calh05t
08-25-2010, 07:06 AM
Dunno if this will work, but I added some simple CMake files (iplug and requirements only, only tested on windows, as i don't have a mac), based on tales repo from today.

http://www.carolander.net/joe/WDL.git/

EDIT: BTW, what's up with the (unused) VSTHosts.cpp?

Tale
08-25-2010, 07:16 AM
http://www.carolander.net/joe/WDL.git/
I can't fetch your repository. When I try I get this error:

fatal: http://www.carolander.net/joe/WDL.git/info/refs not found: did you run git update-server-info on the server?

l0calh05t
08-25-2010, 07:23 AM
I can't fetch your repository. When I try I get this error:

fatal: http://www.carolander.net/joe/WDL.git/info/refs not found: did you run git update-server-info on the server?

can't run anything on the server, as it's just webspace. any way i can prepare my local repository to upload it?

EDIT: ran that command locally and uploaded the generated info/refs, could you try if it works now?

schwa
08-25-2010, 07:29 AM
There does not seem to be a way to simply copy a git repository from a web server that does not have git enabled (though if I have this wrong I'd be glad to know). As far as I can tell, you can't spoof it by generating stuff locally and uploading. The server has to actually be able to do stuff.

Seems like the options are: use a free git hosting service (there are a bunch listed here (http://en.wikipedia.org/wiki/Git_(software)#Source_code_hosting)), or post a git patch file instead of a repository.

[edit] It looks like I have this wrong, according to Tale's next post.

Tale
08-25-2010, 07:34 AM
FWIW, there does not seem to be a way to simply copy a git repository from a web server that does not have git enabled (though if I have this wrong I'd be glad to know).
Well, this is what I do at the moment:

1. git gc
2. git clone --bare . WDL.git
3. cd WDL.git
4. git --bare update-server-info
4. Move (or upload) the WDL.git folder to your webserver

This does seem to work, eventhough I don't have git installed on my webserver.

l0calh05t
08-25-2010, 07:36 AM
hrm, how annoying. anyways here's the patch which hopefully works... www.carolander.net/joe/0002-simple-cmake-CMakeLists.txt-added-windows-only-so-fa.patch

schwa
08-25-2010, 07:36 AM
Tale, if that works, excellent! I couldn't find any specific answer to the question online. l0calh05t, do you want to try that?

l0calh05t
08-25-2010, 07:42 AM
done according to tale's description

schwa
08-25-2010, 07:47 AM
That seemed to work, great!

Tale
08-25-2010, 01:03 PM
I have fetched the Cockos next branch, made a few changes (SerializePresets, Win SDK 7 makefile), and cloned it to my website (also in a next branch). BTW, you certainly will not want to merge in my "567d9fe Added IPLUG_NO_JPEG_SUPPORT to IPlug Xcode project". ;)
Actually you won't want the SerializePresets() thing either, and in fact for now you will want to revert my whole SerializeState() commit (8da3756), because it is no good (yet).

cc_
08-27-2010, 08:01 AM
I have updated my git thingamajig. I reverted all my OSX prompt for user input stuff and anything else that conflicted with tale's stuff, then I added in tale's latest stuff from his next branch. I also removed all my changes to the IPlugExample, sometime soon I'll put together a separate example for my additions.

To get it:

git clone http://evenharmonic.com/WDL.git .

The commit history is a bit of a mess what with all the reversions, but I'm not sure if there's any better way to do things.

bvesco
08-30-2010, 12:44 AM
I'd love to join the git party and start sharing back some of my own tweaks and changes. Here's what I've done so far:

git clone http://www-dev.cockos.com/wdl/WDL.git
git remote add cc http://evenharmonic.com/WDL.git
git remote add l0cal http://www.carolander.net/joe/WDL.git/
git remote add tale http://www.taletn.com/WDL.git
git fetch cc
git fetch l0cal
git fetch tale

Now I think I'm at a point where I can see everyone else's changes. I'm thinking of getting my own branch going and using github to store it all, but have I used the correct set of commands to get set up to do that? Was cloning the core cockos repo the right thing to do? Should I be creating a branch and working from there? How do I cherry-pick changes from others? I could do all this stuff pretty easy in SVN or CVS, but the git way of thinking is quite new to me.

cc_
08-30-2010, 12:58 AM
That looks similar to what I've done, I don't think there's any reason to make a branch unless you need it for something particular - like keeping a master for your plugin and some other for testing stuff out.

I don't think "fetch" is enough though. I have been using "pull" which does a "fetch" and a "merge", so either you will have to do the merge now, or go back and do it again with pull instead of fetch.

Also if you will want to specify tale's "next" branch when you grab his stuff:

git pull http://www.taletn.com/WDL.git next

Tale
08-30-2010, 01:09 AM
First I would try to "publish" your own repository to a temporary local directory:

git clone --bare . WDL_temp.git
cd WDL_temp.git
git --bare update-server-info
cd ..

You can then test your temporary repository by cloning it to another temporary directory:

md foobar
cd foobar
git init
git remote add tempwdl ../WDL_temp.git
git pull tempwdl master


I don't know (yet) how to push your repository to GitHub, but I assume GitHub has some sort of how-to document for this.

cc_
08-30-2010, 01:23 AM
So what's the advantage of doing init, then pull? I started doing it that way, but at some point I switched to just using clone and everything seems to be working fine:


mkdir foobar
cd foobar
git clone ../previous_clone


I'm worried something will bite me later though!

Tale
08-30-2010, 01:35 AM
Well, I'm still a Git dummy, but I think clone doesn't merge, which is why it it better to add a remote and then fetch/pull it.

cc_
08-30-2010, 01:49 AM
Those commands don't need a merge, I just clone in an empty directory (I never do git init).

I too have not much idea what's going on. it's all very scary :)

Tale
08-30-2010, 02:01 AM
The same here, but fortunately for us Git seems to be pretty dummy-proof. :D

The git init is not required when doing git clone, as it already does the init for you. However, it is required when doing git remote add, because else you might add the remote to a git repository higher up the directory tree.

cc_
08-30-2010, 02:58 AM
Yes, it does seem very dummy proof! I don't think I have managed to actually break anything in all my messing about. Or maybe dummies just can't tell when they've broken things :D

So far I haven't been using the remote stuff at all. I've only pulled from repos listed on the command line. I guess I should try and figure that out.

bvesco
08-31-2010, 12:08 AM
Thanks to the help on this forum and a git-savvy coworker I am now online with my own thing.

git@github.com:b-vesco/vfx-wdl.git

Since I'm on github the repo is technically "public" which means anyone can write to it. So I can only ask that you not write to the master and cause me a bunch of headaches of learning how to clean it up back to my own personal version ;) If you want to push code to me, at least create a branch for it.

Unfortunately there doesn't seem to be a clean way to do complex merging while keeping a nice revision graph. For instance, if you cherry pick a revision from another branch and later merge that other branch you now have two different unconnected nodes on your revision graph that both point to the same commit. Confusing and cluttered.

cc_
08-31-2010, 12:21 AM
Unfortunately there doesn't seem to be a clean way to do complex merging while keeping a nice revision graph. For instance, if you cherry pick a revision from another branch and later merge that other branch you now have two different unconnected nodes on your revision graph that both point to the same commit. Confusing and cluttered.

I think this is the result of the cherry picking which as far as I understand produces a commit unrelated to the original commit. This thread seems interesting:

http://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow

reading this an other stuff makes me think cherry picking should be used very carefully.

bvesco
09-01-2010, 01:13 AM
That's a great overview you linked. However, I have not yet figured out how to "git merge" a single commit from the "middle" of some other branch.

l0calh05t
10-18-2010, 07:07 AM
this guy here collected a few Iplug enhancements/changes:

http://www.plugindeveloper.com/tag/iplug

Justin
10-20-2010, 08:07 PM
I've just updated our offical WDL branches (master and next) with 52 commits from our own trees. These are all in LICE, SWELL, and basic functions, and hopefully should only be beneficial (nothing too drastic or anything). I've done the update in git only, if anybody really wants a snapshot that can probably be arranged.

junioreq
10-20-2010, 09:03 PM
Thanks Justin....


~Rob.

Tale
10-27-2010, 12:27 PM
Thanks for the update. I have just pulled the changes into my own WDL edition, and built the latest version (http://www.martinic.com/combov/downloads/) (v1.0.4 RC) of my ComboV project with it. :cool:

sstillwell
10-29-2010, 04:23 PM
Okay, for the love of Pete...has anybody here SUCCESSFULLY built IPlug AND an AU using it in 32/64 bit Universal Binary and actually TESTED it? Carbon (or at least the most of the UI portions of Carbon) don't exist in 64-bit, and this seems to cause much anguish.

I can get IPlug to compile cleanly by excluding IGraphicsCarbon.cpp from the 64-bit build and with judicious use of #ifndef __LP64__ / #endif elsewhere to exclude naughty Carbon bits from IGraphicsMac, but I get link errors in the example plugin pointing back to IGraphicsCarbon members even when there shouldn't BE any references left.

I hate to throw it out there guys, but...help?

Scott

sstillwell
10-29-2010, 11:30 PM
Hmm...clean compile except that now it says it can't find _AUEventListenerNotify at link time (reference coming from four locations in IPlugAU

*sigh*

Sometimes I swear it's just my Mac that is broken.

Scott

asenet
10-29-2010, 11:48 PM
I made it to compile clean (#ifdef all Carbon stuff), but when running in AULab it crashes due to differences in the AU structures (32<->64 bit pointers).

I have put this on my list of todos and it should hopefully happen anytime soon.

sstillwell
11-01-2010, 07:34 AM
Okay, clean compile and link now...had been a bit overzealous in removing what I thought were unused frameworks from the project.

Doesn't WORK, but it compiles and links...back to digging...

Scott

Tale
11-01-2010, 08:36 AM
I have tried building a 64 bit binary a while ago, compiling and linking wasn't much of a problem. However, I couldn't test it, because I don't have a 64 bit Mac...

sstillwell
11-01-2010, 08:47 PM
Core Solo or Duo (not Core 2)Mac Mini? Those are the only halfway-recent machines I know of that won't run a 64-bit capable Mac OS (Leopard, Snow Leopard)

I have a Core 2 Duo Mac Mini running Snow Leopard and an old 'Sawtooth' (AGP Graphics) G4 running Tiger. I finally turned off the G4 and unplugged it earlier this year. Got a lot of good use out of it, though!

Scott

Tale
11-02-2010, 11:22 AM
Core Solo or Duo (not Core 2)Mac Mini? Those are the only halfway-recent machines I know of that won't run a 64-bit capable Mac OS (Leopard, Snow Leopard)

Oh, I see. Well, in that case I stand corrected: I have a fairly modern Core 2 Duo MacBook Pro, so it sure is 64 bit. This just shows what a MacExpert I am... (not!) :o
Anyway, I have retried building a 64 bit AU, but indeed it won't run. It doesn't even get listed as a valid AU.

Tale
11-02-2010, 03:03 PM
After reading this (http://lists.apple.com/archives/coreaudio-api/2009/Aug/msg00224.html) I think the problem might be that there is no x86_64 entry point defined in IPlugAU.r. I don't (yet) know how to fix this though.

sstillwell
11-02-2010, 08:39 PM
Oh, I see. Well, in that case I stand corrected: I have a fairly modern Core 2 Duo MacBook Pro, so it sure is 64 bit. This just shows what a MacExpert I am... (not!) :o
Anyway, I have retried building a 64 bit AU, but indeed it won't run. It doesn't even get listed as a valid AU.

Yeah...the MacBook Pros can't run the x64 KERNEL...can't boot x64. They CAN run x64 code on a 32-bit kernel (as do most other Intel Macs). The MacBook Pro is one of the few machines that can NOT boot x64 (most Mac Minis except for maybe the most recent ones are another). The Mac Pro and, I think, recent iMacs can be made to boot the 64-bit kernel, but boot 32-bit by default. The XServe is the only one that boots 64-bit by default.

They ALL run 64-bit code, though, with the exception of the Core Solo and Core Duo Minis, which had processors that were not 64-bit capable.

TMI, I know. :)

Scott

sstillwell
11-02-2010, 09:42 PM
Progress made!

You were exactly right...we have to define the resources to tell OS X that there is 64-bit code to be loaded.

Pardon the code dump...my GIT isn't accessible outside at the moment.

IPlugAU.r

#include "resource.h" // This is your plugin's resource.h.
#include <AudioUnit/AudioUnit.r>

#define UseExtendedThingResource 1

#include <CoreServices/CoreServices.r>

// this is a define used to indicate that a component has no static data that would mean
// that no more than one instance could be open at a time - never been true for AUs
#ifndef cmpThreadSafeOnMac
#define cmpThreadSafeOnMac 0x10000000
#endif

#undef TARGET_REZ_MAC_PPC
#ifdef ppc_YES
#define TARGET_REZ_MAC_PPC 1
#else
#define TARGET_REZ_MAC_PPC 0
#endif

#undef TARGET_REZ_MAC_X86
#ifdef i386_YES
#define TARGET_REZ_MAC_X86 1
#else
#define TARGET_REZ_MAC_X86 0
#endif

#undef TARGET_REZ_MAC_PPC64
#ifdef ppc64_YES
#define TARGET_REZ_MAC_PPC64 1
#else
#define TARGET_REZ_MAC_PPC64 0
#endif

#undef TARGET_REZ_MAC_X86_64
#ifdef x86_64_YES
#define TARGET_REZ_MAC_X86_64 1
#else
#define TARGET_REZ_MAC_X86_64 0
#endif

#if TARGET_OS_MAC
// quad fat binaries
#ifdef TARGET_REZ_MAC_PPC && TARGET_REZ_MAC_X86 && TARGET_REZ_MAC_X86_64 && TARGET_REZ_MAC_PPC64
#define TARGET_REZ_FAT_COMPONENTS_4 1
#define Target_PlatformType platformPowerPCNativeEntryPoint
#define Target_SecondPlatformType platformIA32NativeEntryPoint
#define Target_ThirdPlatformType platformX86_64NativeEntryPoint
#define Target_FourthPlatformType platformPowerPC64NativeEntryPoint
// dual fat binaries
#elif TARGET_REZ_MAC_PPC && TARGET_REZ_MAC_X86
#define TARGET_REZ_FAT_COMPONENTS_2 1
#define Target_PlatformType platformPowerPCNativeEntryPoint
#define Target_SecondPlatformType platformIA32NativeEntryPoint
// single-architecture binaries
#elif TARGET_REZ_MAC_X86
#define Target_PlatformType platformIA32NativeEntryPoint

#elif TARGET_REZ_MAC_X86_64
#define Target_PlatformType platformX86_64NativeEntryPoint

#elif TARGET_REZ_MAC_PPC64
#define Target_PlatformType platformPowerPC64NativeEntryPoint

#else
#define Target_PlatformType platformPowerPCNativeEntryPoint

#endif
#define Target_CodeResType 'dlle'
#define TARGET_REZ_USE_DLLE 1
#else
#error get a real platform type
#endif // not TARGET_OS_MAC

#ifndef TARGET_REZ_FAT_COMPONENTS_2
#define TARGET_REZ_FAT_COMPONENTS_2 0
#endif

#ifndef TARGET_REZ_FAT_COMPONENTS_4
#define TARGET_REZ_FAT_COMPONENTS_4 0
#endif

// ----------------

//#ifdef _DEBUG
// #define PLUG_PUBLIC_NAME PLUG_NAME "_DEBUG"
//#else
#define PLUG_PUBLIC_NAME PLUG_NAME
//#endif

#define RES_ID 1000
#define RES_NAME PLUG_MFR ": " PLUG_PUBLIC_NAME

resource 'STR ' (RES_ID, purgeable) {
RES_NAME
};

resource 'STR ' (RES_ID + 1, purgeable) {
PLUG_PUBLIC_NAME " AU"
};

resource 'dlle' (RES_ID) {
PLUG_ENTRY_STR
};

resource 'thng' (RES_ID, RES_NAME) {
#if PLUG_IS_INST
kAudioUnitType_MusicDevice,
#else
kAudioUnitType_Effect,
#endif
PLUG_UNIQUE_ID,
PLUG_MFR_ID,
0, 0, 0, 0, // no 68K
'STR ', RES_ID,
'STR ', RES_ID + 1,
0, 0, // icon
PLUG_VER,
componentHasMultiplePlatforms | componentDoAutoVersion,
0,
{
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_PlatformType,
#if TARGET_REZ_FAT_COMPONENTS_2
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_SecondPlatformType,
#elif TARGET_REZ_FAT_COMPONENTS_4
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_SecondPlatformType,
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_ThirdPlatformType,
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_FourthPlatformType,
#endif
}
};

#undef RES_ID
#define RES_ID 2000
#undef RES_NAME
#define RES_NAME PLUG_MFR ": " PLUG_PUBLIC_NAME " Carbon View"

resource 'STR ' (RES_ID, purgeable) {
RES_NAME
};

resource 'STR ' (RES_ID + 1, purgeable) {
PLUG_PUBLIC_NAME " AU Carbon View"
};

resource 'dlle' (RES_ID) {
PLUG_VIEW_ENTRY_STR
};

resource 'thng' (RES_ID, RES_NAME) {
kAudioUnitCarbonViewComponentType,
PLUG_UNIQUE_ID,
PLUG_MFR_ID,
0, 0, 0, 0, // no 68K
'STR ', RES_ID,
'STR ', RES_ID + 1,
0, 0, // icon
PLUG_VER,
componentHasMultiplePlatforms | componentDoAutoVersion,
0,
{
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_PlatformType,
#if TARGET_REZ_FAT_COMPONENTS_2
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_SecondPlatformType,
#elif TARGET_REZ_FAT_COMPONENTS_4
cmpThreadSafeOnMac,
Target_CodeResType, RES_ID,
Target_SecondPlatformType,
#endif
}
};

#undef RES_ID


Note that the CarbonView resources are only defined for PPC and IA32, even when a quad-fat binary is specified...they don't exist on 64-bit. Don't know if that's correct or not, but there y'go.

AULab recognizes the 64-bit plugin when launched in 64-bit mode (if you don't know how that works...do a "Get Info" on the application and uncheck the box "Launch in 32-bit mode", then launch it). It crashes when AudioUnitGetPropertyInfo calls down into the IPlugAUEntry, so there's something else busted...but this is progress!

Crashes thus:



Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000810000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 ...chwa.audiounit.IPlugExample 0x0000000113db1db8 IPlugAU::IPlugAUEntry(ComponentParameters*, void*) + 392
1 ...apple.audio.units.AudioUnit 0x00007fff8115dfbf AudioUnitGetPropertyInfo + 59
2 com.apple.audio.aulab 0x0000000100002d99 0x100000000 + 11673
3 com.apple.audio.aulab 0x000000010005002d 0x100000000 + 327725
4 com.apple.audio.aulab 0x000000010004d928 0x100000000 + 317736
5 com.apple.audio.aulab 0x000000010004e62e 0x100000000 + 321070
6 com.apple.audio.aulab 0x000000010004de9d 0x100000000 + 319133
7 com.apple.audio.aulab 0x000000010003d5d8 0x100000000 + 251352
8 com.apple.audio.aulab 0x000000010006ebb5 0x100000000 + 453557
9 com.apple.AppKit 0x00007fff82b40ae9 -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 1515
10 com.apple.AppKit 0x00007fff82b3ecd9 loadNib + 226
11 com.apple.AppKit 0x00007fff82b3e3ec +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] + 763
12 com.apple.AppKit 0x00007fff82b3e021 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 326
13 com.apple.AppKit 0x00007fff82b3b5a3 NSApplicationMain + 279
14 com.apple.audio.aulab 0x000000010000147c 0x100000000 + 5244


Scott

Tale
11-03-2010, 08:05 AM
Using your IPlugAU.r my plug-in now also crashes, so at least it gets recognized. :cool:

EDIT: My 64-bit plug-in crashes in IPlugAU::IPlugAUEntry(), case kAudioUnitGetPropertyInfoSelect, when it tries to execute *pWriteable = false.

sstillwell
11-03-2010, 07:58 PM
Using your IPlugAU.r my plug-in now also crashes, so at least it gets recognized. :cool:

EDIT: My 64-bit plug-in crashes in IPlugAU::IPlugAUEntry(), case kAudioUnitGetPropertyInfoSelect, when it tries to execute *pWriteable = false.

Look at this snippet from AUDispatch.cpp...part of Apple's AU class hierarchy...


#if __LP64__
// comp instance, parameters in forward order
#define PARAM(_typ, _name, _index, _nparams) \
_typ _name = *(_typ *)&params->params[_index + 1];
#else
// parameters in reverse order, then comp instance
#define PARAM(_typ, _name, _index, _nparams) \
_typ _name = *(_typ *)&params->params[_nparams - 1 - _index];
#endif


And then look at the definition of GET_COMP_PARAM in IPlugAU.cpp. Why on earth would they reverse the order of everything on 64-bit platforms? It's not (or shouldn't be) an endian thing...

I suspect this is a good part of why it's crashing...but I could of course be wrong.

My brain hurts.

Scott

Tale
11-04-2010, 09:31 AM
I suspect this is a good part of why it's crashing...but I could of course be wrong.
Yes, that's it, you've cracked the case! I now have a hacked x64 AU version of ComboV running on REAPER x64. :D


My brain hurts.
No, no, no, my brain in my head. ... It will have to come out. :p

sstillwell
11-04-2010, 10:14 AM
Yes, that's it, you've cracked the case! I now have a hacked x64 AU version of ComboV running on REAPER x64. :D

VERY cool. How did you wind up doing that to make it compatible across 32/64 bit? Macro changes like Apple does, or did you just #ifdef the whole section of code and reverse the index numbers?

Scott

Tale
11-04-2010, 02:07 PM
How did you wind up doing that to make it compatible across 32/64 bit? Macro changes like Apple does, or did you just #ifdef the whole section of code and reverse the index numbers?
I used a variation on Apple's macro:

#if __LP64__
#define GET_COMP_PARAM(TYPE, IDX, NUM) *((TYPE*)&(params->params[NUM - IDX]))
#else
#define GET_COMP_PARAM(TYPE, IDX, NUM) *((TYPE*)&(params->params[IDX]))
#endif

And then:

case kAudioUnitGetPropertyInfoSelect: {
AudioUnitPropertyID propID = GET_COMP_PARAM(AudioUnitPropertyID, 4, 5);
AudioUnitScope scope = GET_COMP_PARAM(AudioUnitScope, 3, 5);
AudioUnitElement element = GET_COMP_PARAM(AudioUnitElement, 2, 5);
UInt32* pDataSize = GET_COMP_PARAM(UInt32*, 1, 5);
Boolean* pWriteable = GET_COMP_PARAM(Boolean*, 0, 5);

Etc. etc.

sstillwell
11-04-2010, 07:57 PM
Right on! Working here, as well. Don't have a G5 to test PPC64 against, but I'll bet that's fine too.

Yay us. :)

Scott

Tale
11-06-2010, 02:54 AM
Don't have a G5 to test PPC64 against, but I'll bet that's fine too.
Do you think there are a lot of PPC64 Macs out there? I was thinking of keeping my current PPC/Intel 32-bit OS X 10.0.4 build, and add an OS X 10.0.5 Intel 32/64-bit build with no PPC support.

BTW, I have found a couple of issues with IPlugAU.r (#ifdef where it should read #if, won't build for just 1 platform), and I have added more dual "fat" combinations. My Git repository (http://www.taletn.com/WDL.git) contains an updated version.

sstillwell
11-07-2010, 12:17 AM
Do you think there are a lot of PPC64 Macs out there? I was thinking of keeping my current PPC/Intel 32-bit OS X 10.0.4 build, and add an OS X 10.0.5 Intel 32/64-bit build with no PPC support.

BTW, I have found a couple of issues with IPlugAU.r (#ifdef where it should read #if, won't build for just 1 platform), and I have added more dual "fat" combinations. My Git repository (http://www.taletn.com/WDL.git) contains an updated version.

Any G5 processor is 64-bit, and parts of the OS and libraries have been 64-bit enabled since 10.2-ish. Otherwise there would be no point in G5s with 8 GB of RAM, which weren't that uncommon.

I've got some of my plugs up and running now on x64...yay! Lots of work remaining, but forward motion is...err...going forward!

Scott

RRokkenAudio
11-22-2010, 01:23 AM
What do you need to do, to host your git on your page. Can't find any info...Hopefully i don't need a dedicated host just for git heh.

Tale
11-22-2010, 01:36 AM
I run the following commands to create a "bare" repository in a directory called WDL.git:

git clone --bare . WDL.git
cd WDL.git
git --bare update-server-info

I then upload the WDL.git directory to my webserver using FTP (in binary file mode).

bvesco
11-22-2010, 01:50 AM
What do you need to do, to host your git on your page. Can't find any info...Hopefully i don't need a dedicated host just for git heh.

You can use github for a free online repo that is already git-ified.

sstillwell
11-22-2010, 08:20 AM
You can use github for a free online repo that is already git-ified.

Only if the project is going to be open-source. I know, you generally wouldn't have it on a publicly accessible server if it WASN'T open-source, but it's worth clarifying.

Github has paid plans that allow closed-source repositories, but to qualify for free hosting it has to be open-source.

Scott

bvesco
11-23-2010, 10:04 AM
@Scott

Yes, only if the project is open source. I believe Rob's goal was to find hosting for his personal modifications to WDL and IPlug to be shared with the community here, not for hosting the source code of his plugins. With that in mind Github is still an appropriate solution because Rob can keep his WDL mods public and open source while hosting his actual plugin code elsewhere.

olilarkin
12-17-2010, 11:22 AM
i finally got around to using git. one thing i'm not sure of is if i should have a WDL.git or just a .git

Are you guys renaming the .git directory when you upload it?

thanks,

oli

Tale
12-17-2010, 11:56 AM
Actually I clone my Git repository to a bare repository already called WDL.git, and then I upload this bare repository, see here and/or here.

olilarkin
12-17-2010, 12:08 PM
cool, got it.

here is my one http://www.olilarkin.co.uk/dev/WDL.git/

oli

olilarkin
12-18-2010, 04:35 PM
if anyone's interested i just uploaded a new version with a template project and duplication script that i use to rapidly set up new projects. It copies the template folder and does a multi-file find and replace (in file names and class names). It builds for win32 and x64 (although i didn't test the x64 binaries yet). Next i'll add the 64bit au support.

The template has some useful debugging stuff set up already.

Note: both the visual studio project and xcode project are not building the static library, they just include all the necessary iplug sources

note #2: the duplicator script only works on osx at the moment

Tale
06-24-2011, 04:23 AM
The zlib and libpng versions that come with Cockos WDL are a bit outdated. This is not necessarily a bad thing (don't fix what isn't broken?), but I nevertheless have updated both libs to the latest stable versions. If anyone wants to cherry-pick these updates, here are the two commits in my Git repository:

5af40e7 zlib: Updated to v1.2.5.
98b845f libpng: Updated to v1.5.2.

If you do cherry-pick these, then you will probably have to do some minor changes to your project files (see the full descriptions for both commits).

Justin
01-08-2012, 01:51 PM
The zlib and libpng versions that come with Cockos WDL are a bit outdated. This is not necessarily a bad thing (don't fix what isn't broken?), but I nevertheless have updated both libs to the latest stable versions. If anyone wants to cherry-pick these updates, here are the two commits in my Git repository:

5af40e7 zlib: Updated to v1.2.5.
98b845f libpng: Updated to v1.5.2.

If you do cherry-pick these, then you will probably have to do some minor changes to your project files (see the full descriptions for both commits).

Just pushed updates to the main Cockos WDL repos, including the new libpng above (though we still use old 1.2.3 zlib, I think)... Thanks, Tale! :)

Tranquil
01-08-2012, 03:33 PM
Just pushed updates to the main Cockos WDL repos, including the new libpng above (though we still use old 1.2.3 zlib, I think)... Thanks, Tale! :)

Is there a particular technical reason not to update to zlib 1.2.5 or it's just the result of boredom?

also changed pngstruct.h include

diff --git a/source/WDL/libpng/pngstruct.h b/source/WDL/libpng/pngstruct.h
index 33f2384..5780901 100644
--- a/source/WDL/libpng/pngstruct.h
+++ b/source/WDL/libpng/pngstruct.h
@@ -24,7 +24,7 @@
* in this structure and is required for decompressing the LZ compressed
* data in PNG files.
*/
-#include "zlib.h"
+#include "../zlib/zlib.h"

struct png_struct_def
{

Tale
01-09-2012, 01:46 AM
Just pushed updates to the main Cockos WDL repos, including the new libpng above (though we still use old 1.2.3 zlib, I think)... Thanks, Tale! :)
You are welcome, and thank you for updating WDL. :)

BTW, my post above was about libpng v1.5.2, but since I have updated it to v1.5.6, which is also included in the updated Cockos WDL.

-#include "zlib.h"
+#include "../zlib/zlib.h"
Alternatively you could tell you compiler to look for include files in ../zlib. ;)

Justin
01-09-2012, 11:48 AM
Ooops I lied, we are on 1.5.6 as well. Though neat 1.5.7 is out.

Tale
01-09-2012, 03:29 PM
Though neat 1.5.7 is out.
It's already hard just to keep up with you sometimes, let alone stay ahead of you... But here you go: I have updated to libpng v1.5.7 (commit c091f24 in my WDL edition). :D

Tale
02-10-2012, 03:57 PM
I have just updated libpng to v1.5.8 (see commit d31310c), which includes a fix for a buffer-overrun vulnerability in v1.5.7.

Tale
03-06-2012, 05:58 AM
Yup, another vulnerability fix in libpng, so I have updated to v1.5.9 (commit 79e5edc7fa in my repository).

Tale
05-08-2012, 04:03 AM
FYI: I have updated my WDL's libpng to v1.5.10, and zlib to v1.2.7.

Argitoth
10-20-2014, 09:56 AM
There is 'k' and 'm' at the beginning of many variables. What do they represent?

Tale
10-20-2014, 10:13 AM
There is 'k' and 'm' at the beginning of many variables. What do they represent?
The m for member variable, the k for constant (I think). Sometimes you will also see g for global, s for static, and e for enumerator. These prefixes are used to distinguish beteen normal (local) variables, and member/global/static variables or constants/enumerators. Note that you don't have to use these prefixes, but it is considered good practice.

class MyClass
{
...

int mY;

void Square(int x)
{
int y = x*x;
mY = y;
}
};

sstillwell
10-20-2014, 10:14 AM
There is 'k' and 'm' at the beginning of many variables. What do they represent?

'k' usually represents a (k)onstant, and 'm' is usually a (m)ember variable in a class.

Scott

Argitoth
10-20-2014, 10:15 AM
two replies for the price of 1, thanks!