Hello, and welcome back to part 2

of building your own Processing library in Java.

Look, I'm working with Eclipse!

I love eclipse!

All of you will complain that I'm using Eclipse,

and I don't care.

I love Eclipse.

It's one of the first places I learned to program,

so it has a special place in my heart.

So what I did in the previous part--

you're probably going to want to go back to watch it

if you're here and you didn't--

was set up the development environment,

so install Eclipse, make sure I have Processing installed,

setup all the paths, the build paths, the project,

the template, the cloning, all of that stuff.

So what I am here right now, I successfully built the library.

So it shows up now in Processing under Import Library.

And, remember, I'm choosing OpenSimplexNoise as the topic.

It's very arbitrary, but I want to build something

that's actually useful and can be published as a real library.

But the library is here, but if I click this,

it automatically adds the import statement,

which you can see is just template.library.*.

So in this video, what I want to do is code the library itself

and make one example that uses it.

Probably the hardest part of making a library

is being thoughtful about the design

of the library API itself, how you make the examples,

as well as documenting it.

So that's more of a broader topic related

to how to maintain and publish an open-source library,

but I'm going to mostly focus on the technical details

of building the thing.

And maybe towards the end, I can circle back and talk more

about those key important concepts and topics

to having a healthy open-source project.

So first thing that I want to do,

if I want to customize this, it I

should say something like "import

shiffman.opensimplexnoise," or something like that.

I mean, I don't think that's what I'm going to call it.

I'm going to go back to Eclipse.

I'm going to go over here, and I'm looking for under Source.

And so, look, this is what's known as a package,

template.library.

And so, because the package name in the template

is just "template.library," that's what the import was,

template.library.

So I'm going to right-click on this,

I'm going to go to Refactor, and click Rename.

And then I'm going to come here, and I

got to pick a name for it.

Let's call it "algorithms.noise."

Ultimately, I think what could be exciting

about this library is to implement

a bunch of different noise algorithms, OpenSimplex

noise, fractal noise, gradient noise, Worley noise.

So many different kinds of noise algorithms

could be in here that would be additions and enhancements

to the built-in, original Perlin noise algorithm that's

in Processing itself.

So that'll be my name.

I'm going to click OK, excellent.

Now I want to go into the source code, which

is called "HelloLibrary."

So I am going to rename this also

by going to Refactor, Rename.

And I'm going to name that--

let's call this particular Java class "OpenSimplexNoise."

And I'm going to do Finish.

OK, great.

I'm going to go over here, and there we go.

Let's try rebuilding the library.

We don't need to rebuild it at every single stage,

but let's just rebuild it to see if what I did at least

shows up with the proper naming conventions.

So I go to Window, Show View, Ant.

Click here, and do Ant Build.

BUILD SUCCESSFUL is what you're looking for.

Go back to Processing, Sketch, Import Library,

OpenSimplexNoise.

There we go!

Interestingly, it's giving me an error message.

Let's try restarting Processing and see what happens.

All right, I restarted Processing,

and the error message went away.

So certain things that you change,

if you're changing the package name,

even though the new library files

are being built and brought over into Processing,

Processing has loaded what it thought all the package

names were when it started up, so you have to restart.

So I don't think with every single change

you make while you're building the library you're

going to have to restart Processing,

but that certainly is something you'll

have to do from time to time.

One of the things I like to do when

designing an open-source library is actually

write the example first in the way

that I imagine that it might be.

So even though I haven't built any

of the functionality of the library itself,

what I want to do is I want to take a simple processing

Perlin noise example that uses just

the built-in original Perlin noise from the 1980s algorithm,

and then change that example to use OpenSimplex noise.

So if I go to Examples, under Basics,

under Math, let's just take Noise1D,

and let's look at this example.

This Noise1D example is mapping the x location

of this circle it's drawing to the noise

implementation in Processing.

So I'm going to grab all this code,

copy it, close this out, and paste it in here.

And I'm going to imagine what I might do.

So I might do something like, OpenSimplexNoise noise.

And then I'm going to say "noise is a new OpenSimplexNoise."

So presumably the idea is that OpenSimplexNoise

would be an object inside of the package algorithms.noise.

Maybe I want to name that just "OpenSimplex,"

because by definition it's noise.

Who knows, but I want to create a new instance of it.

Maybe, optionally, there could be

a seed that goes in here, because I could

be randomly seeding the noise.

And then, what I would do is, say--

(CHUCKLING) and so let me call it something different

for it to be less confusion.

Let me call it "osnoise" for OpenSimplexNoise.

And then, probably what I would want to do is say

"osnoise.value," pass it this X offset.

And, actually, that's it!

Because, really, this is such a like--

even though the OpenSimplexNoise algorithm is quite complex,

I just want one function that gives me the noise value back.

And I'll call that value-- or, I could have called it "noise."

I don't know what to call it.

But, again, these types of naming an API design decisions,

while incredibly important, I'm going to maybe tackle later,

and through user testing and discussion,

and are less crucial right now in terms of the nuts and bolts

of how to build your library.

How to think about making an open-source library,

it's so important!

But right now I can just pick something.

Let's pick value.

Let me go back to the library code.

And I'm going to add a function now.

I'm going to add a function called "public value."

And it's going to receive an argument, like X offset, xoff.

And I'm going to say "return negative 5."

So I just want to test out this idea.

I want to add a function called--

oh!

This should be "public float value."

Because it's a Java function that returns a float.

It receives a float.

So, again, this is not the OpenSimplexNoise (CHUCKLING)

algorithm, but I am just going to have it return

negative 5 to see if it works.

And let's actually just give it the number 50.

Well, actually, noise should return a value between 0 and 1

or, in this case, maybe between negative 1 and 1.

So let's actually make it negative 0.5.

And, in Java, if I want it to be a float,

I've actually got to add that f to indicate float.

So, once again, I am going to build the library.

The library is rebuilt. Let's go back to the code.

Oh, wait, I'm getting an error.

"The constructor OpenSimplexNoise noise

is undefined."

Why am I getting that error?

Because I have a constructor OpenSimplexNoise--

oh!

It needs this thing, PApplet theParent.

Ah-ha!

What this is and how this works, PApplet theParent,

is probably something I should tackle or address

in maybe a third part or a fourth part to this series

because I don't think that I need it

for this particular OpenSimplexNoise library.

But this is a way of having the library know something

and communicate to or execute functions in the user's sketch

itself.

It's not something I initially need for OpenSimplexNoise,

but let me just keep it in here for right now.

I'll decide later if I can remove it.

But there's-- this is not a flaw of the library design.

It's now a flaw of my code where I need to say "this."

The keyword "this" in Java refers to "this class,"

and your Processing sketch is actually

a class that's just hidden from you when you're

working in Processing itself.

So now let me run this.

And we could see the negative 320.

Why is it negative 320?

Because I'm multiplying it by width.

So that's right, width is 640.

The only noise value I ever get back

is negative 0.5, multiplied by width is 320.

So now we're building the library

and we added our own function to a particular class

in the library itself.

The next step is let's actually put in the OpenSimplexNoise

algorithm.

Here is the r-- it's raw source code for Kurt Spencer's 2014

implementation of OpenSimplexNoise in Java.

Now, there's a little bit of an unfortunate

thing, which this class is also named "OpenSimplexNoise."

Again, here I am back to this naming thing.

Everything is quite difficult, but let's--

let me first just bring this into Eclipse.

So there's a variety of ways I could do that,

but I'm just going to copy paste it.

So I'm going to make-- here, I'm going to create a new class.

And I'm going to call it "OpenSimplexNoiseKS,"

the KS for Kurt Spencer's.

I want to keep that implementation entirely intact.

So I'm going to hit Finish.

I am going to paste it in, and then I am going to hit Save.

And then, I need to change this to KS.

I need to add the package declaration.

And then, I need to find other things.

Like, this should be KS, this should be KS,

this should be KS, this should be KS.

There we go.

Now that I have the OpenSimplexNoise original

implementation from Kurt Spencer as a separate class

here in my library, I have a decision to make.

Ultimately, what I want is for that functionality

to appear in my OpenSimplexNoise class.

And so I could extend the OpenSimplexNoiseKS class,

that would be known as inheritance.

Or I could really just wrap it by making an object in here,

like OpenSimplexNoiseKS generator that

is an instance of Kurt Spencer's OpenSimplexNoise

implementation.

And this is referred to as composition,

maybe like wrapping another class as an instance

inside of a class.

So the reason why I want to do this is I'm trying to--

I'm not trying to expose the full implementation

and just add a few window dressing things to it.

Although, that would be a legitimate way

of designing this library.

But I'd rather do it this way just to really hide that,

but have my own set of functions that make use