Set up Your *Second* Program

The OPENRNDR Guide has a post titled Setup Your First Program

But what about your second program? When I started experimenting with OPENRNDR I remember thinking that I should repeat this process every time: clone the template, wait for indexing, etc. Not ideal if you want to create lots of experiments.

BUT

It’s not necessary! :slight_smile:

You can stick to one template!

Instead of editing src/main/kotlin/TemplateProgram.kt directly, every time I want a new program I right click on that file to copy & paste (= duplicate) giving it a new name.

If a program grows to be 2 or 3 files I create a package for it and move those files into that package. That way I can iterate fast and jump between experiments within one IDE project.


Maybe a bit messy but hey, it’s my playground :slight_smile:

One drawback may be that all files need to be in a compilable state. That means that you can’t leave a file mid sentence and continue with another file. That mid sentence needs to be commented out. In some cases I comment out the whole file if it’s not the right time to work on it.

What are your approaches and tricks to experimenting and iterating?

ps. One nice feature of the Screenshot() extension is that it saves the image with the name of the file that produced it. Same when exporting video files. That means that even if I only have one screenshots folder, the files are automatically named after the kotlin program that produced it. Super convenient!

2020-04-11-101007_394x324_scrot

This is exactly how I use my OPENRNDR projects. I usually start with a clone openrndr-template for each project that I do. I make a lot of iterations on sketches, which I keep track of by numbering them. I usually use a two-digit numbering system for that, e.g: Sketch01, Sketch02 and so on.

Both the Screenshots and ScreenRecorder extensions are used extensively. Code has the tendency to break over time (unless you are very careful, but that’s maybe not in everybody’s time budget), so it is great to have at least some visual documentation of that code around. I often share videos and screenshots with coworkers and clients to communicate ideas. A lot of the work that is made while sketching things does not make the cut. It is great to have screenshots and videos around for later, it has helped me a lot to be able to quickly respond to pitches.

Also my playground projects are placed in git repositories. I usually do this by removing the .git folder and running git init. I mainly use git to be able to transport projects between multiple machines, but sometimes it is handy to hand-over your playground to someone else.

2 Likes