Luppp: Update 4

Hey,

Lots of time has passed since the last update, here's the latest.

• Preliminary sequencing has been implemented. Eg: get to bar beat tick 0, record a loop of OSC stuff, reverse to BBT 0 again, and it will play back. Currently this is being implemented in a "normal" fashion (OOP not hack)..

• -Though has been going about the OSC interface. I'm seriously concidering using sigc++ signals instead. Reasons: Liblo is pretty hard to compile for windows. It depends on pthreads, again hard to compile. OSC ports sometimes stay "used" and the server cant start. Disadvantage is the loss of OSC support and lots of work. :-( tough choice.

• Also trying to work out how to neatly have a mixer for the signals with sends & returns, while keeping the code understandable... its fun!

Till next, -Harry

Luppp: Update 3

Heyo,

Again some progress. A Sequencer class has been thought up, and how it will interact with JACK timebase or its own timebase. Great advice was provided by a a software systems lecturer, and I'm confident that when done the sequencer part of the engine will perform quite well despite there being no direct connection from the other parts of the program to it.

Other updates: I'm currently converting the build system to CMake. Reason: Waf claims its cross-platform, but since I'm using it, I've not compiled Luppp on windows. So there was need for some change there, to allow proper CP operation.

The CodeBase isnt growing at all at the moment, but it is stabilizing & being upgraded to have better functionality & efficiency... (Ie: No creating a float array of nframes size each time process is called!

Till  next, -Harry

Luppp: Update 2

Hey,

Just to keep up to date, the Luppp sampler is know in 16 sample working mode. There's still some number checking to be done, (ie: sending play(17); will segfault the engine), however there's definatly good progress!

The Mixer has been gave a facelift, (note the screenshot in previous post.. its a little "simple"). Now its getting a little extra spices.

Plans for OSC feedback are in place, I've decided to bounce all incoming OSC data that goes to Luppp's engine (@ 14688:"/luppp/*") to 14687:"/luppp/feedback/*".  That means that if you want to connect your controller that has moving faders, or a screen, you can, and using a quick python script.

Ill be writing one for a Frontier Design Alphatrack (I own one.. so might as well give it full support). Also, I intend to send each Sampler NoteOn/Off to /feedback, so any drumPads that can light up will do so when the sampler is played by clicking the GUI.

Lots of progress, lots more to be had. Helping myself here, Till next: -Harry

Luppp: Update

Hey,

Luppp development is still in progress, as anybody
following the Git repo would know. There's been quite
a few check-ins lately, and progress has definatly been
made.

Although I removed the (already working) PyGame sampler,
a new C++ JACK enabled sampler is taking its place, and is
almost at "working" status. (note it still is lacking features like
LADSPA plugins etc).

The Engine and GUI have been TOTALLY separtated, to the
degree where 2 terminals are needed to run them. :-)
I like this approach from LinuxSampler, as it allows "headless"
operation really easily, and removes internal ties & hard to visualize
links in the program.

The communication done using OSC is what i'd call a "bounce" system.
Reason for this is that if you click on a Sampler, the OSC SamplerPlay
command gets sent, which makes the Engine play a sample, and then
the Engine sends a command to the GUI, telling it to highlight the Sampler
you clicked on. Ie: if the Engine didnt manage to do whatever it is you asked
it to, its not going to fail silently, but the GUI wont reflect the changes
you've made.

Is this good practice? I think so, its a little more work.
(perhaps? Some might disagree) But the possibilities are
much better. (I think).

Attached are 2 screenshots, just to show the progress.
Till next, -Harry

Tut 9: Dropping your IDE

Hi,

So far, I've been using an IDE for most of the tutorials I've done.
To get "real" cross-platform compilation, and not make everyone
else use the same IDE as you to work on a certain project, you
need to adapt to a Build System.

The most common build system in the past was Make. (& freinds.)
Originally developed years ago, I think it was a revolution. But now
I think its an outdated, unusable piece of software.

Waf: Please stand up:
Waf is a new build system, based on Scons, and its written in Python.
This means that to use Waf, you dont need to learn any "new"
scripting language, all you need to do, is learn a couple of "keywords"
that will use waf to build your program.

 There's a zip here, which has a "full C++ demo" of Gtkmm & Waf.
Inside the zip, there's a file called ReadMeToComplie.sh
If you open it with a text editor, you'll get a run through of how to use
Waf.  If you open a terminal in that location, and type:
./RunMeToCompile.sh
Its going to configure, build, run, and then clean up your program.
Ie: Prepare to build, Build, Run, and Remove the compiled program.

Hope that's a help to those looking for a simple tut, -Harry

Tut 8: Loading a Glade UserInterface file. (Gtk::Builder)

Hey guys,

As you may have noticed I've slowed a little on the tutorials,
mainly due to working on Luppp quite a bit. Here's a quick
one on how to load up a glade file though. Note that it does NOT
use libGlademm, rather Gtk::Builder, the newer version.

Gtk::Builder doesn't have any external dependencies outside of Gtkmm,
so its a good idea to switch to it. (there are also technical differences, but
they're outside the scope of this tutorial.)

Here we go: Code!
There's a .zip attached here, with well commented main.cpp inside, as well as a file called basic.ui, which is the Gtk::Builder User Interface.

I've decided its a bit cleaner to put my code in the .zips rather than here on
the blog, so expect a link to a zip in most tutorials!

Till next time, -Harry

The Luppp Project

Hey all,

I've started a project a good while back, called Luppp.
Its a live looper. Woohoo you think, another one. Yes.

Why?
(IMO) Some loopers:
- dont stimulate the creative musical side in an artist. (look ugly)
- have too much functionality. (buffer features, advanced menu's)

- only support MIDI or Audio, (multiple programs = messy desktop)
- "feel" too laggy.. (Ableton's UI?)

Why go to the bother of writing it yourself? Well somebody needs to,
and there are other efforts going on (Check Composite, Seq24).
Although Seq24 is a great MIDI looper, I always find the music I make using it is the "same old" song I do every time.

How is Luppp being built?
C++ baby. And Python. And OSC.
Currently the UI is totally built using Gtkmm & C++ , for fast widget drawing.
Python is used as the "prototype" for backends.
OSC is implemented in both the UI & the backend, to allow flexibility in "how" you use the program.

UI:
Gets loaded from a GtkBuilder XML file, signals get connected to appropriate parts of it, and its shown. The rest is handled by callback functions in C++.

Backends:
Currently written in Python, although I do intend to move these over to C++ once nessisary. They currently "do" the stuff you want Luppp to.

OSC:
The Luppp UI has an OSC server. This means you can send commands to Luppp, and it will respond as if you clicked somewhere. This is an amazing feature, as it allows ALL parameters inside Luppp to be controlled using external hardware if you want to. So "No-Computer-Nessisary" kinda applies.

When can we expect an Alpha release?   : Buzz off. Ill let you know.
Where can we get your source code?       : Download it here.
How can we informed when its released?: LinuxAudioAnnounce & a post here.

Cheerio, -Harry