Hey,
Luppp got its chrismas pressie early: Live audio input. As well as this, the start of a "timeline" class has been made, and this allows any recorded loops to stay in sync with eachother... :-)
GUI stuff has been deleted except for the re-usable stuff, and over the next while I intend to get some basic waveform & mixer widgets implemented. That is if i can stop myself recording all sorts of crazy sounds & looping them.
Till next, -Harry
A blog dedicated to Linux Audio. Some Programming tutorials will be posted, some howTo articles for using certain features of a program, or just my own thoughts/options on any topic.
Sunday, December 19, 2010
Saturday, December 18, 2010
Luppp: Update? Nah News!
Hi.
Here's the deal: Luppp has been brought back to life. Not only same code is being re-used, but other projects have joined forces and now co-exist with Luppp.
This makes all the features from the other projects easier to implement in Luppp, like looping a .wav file, like processing automation data, providing LADSPA plugins.. :-)
The front-end needs work dratically, its basically just an OSC & terminal application atm. But that's all gonna change. Plans are made to scrap the "internal OSC" mode, in favour of being able to access the waveform data etc in the GUI thread. Nessisary evil for a nice program. Oh well.
Also the GUI will be totally reworked from 0, just like the engine was. This will provide more stable & maintainable code, as what I wrote a couple of years ago isn't quite what most would concider acceptable.. :-P
Will post here once there's new features... -Harry
Here's the deal: Luppp has been brought back to life. Not only same code is being re-used, but other projects have joined forces and now co-exist with Luppp.
This makes all the features from the other projects easier to implement in Luppp, like looping a .wav file, like processing automation data, providing LADSPA plugins.. :-)
The front-end needs work dratically, its basically just an OSC & terminal application atm. But that's all gonna change. Plans are made to scrap the "internal OSC" mode, in favour of being able to access the waveform data etc in the GUI thread. Nessisary evil for a nice program. Oh well.
Also the GUI will be totally reworked from 0, just like the engine was. This will provide more stable & maintainable code, as what I wrote a couple of years ago isn't quite what most would concider acceptable.. :-P
Will post here once there's new features... -Harry
Sunday, December 5, 2010
Exams Idea's and Audio
Hey guys,
With exams looming in the next two weeks and projects to be finished there's definatly enough to be done. At the same time there's some nice ideas popping up around the place.
I've understood the C++ principle of composition, which will allow for neater more sustainable code. In my mind there's some better idea's of how Luppp Automate reSampler etc need to be integrated into one larger program.
Also some messing about with a windows build has been done... apart from LibLO, and Pthreads I've got most of it sorted out. :-)
Next update after the exams! -Harry
With exams looming in the next two weeks and projects to be finished there's definatly enough to be done. At the same time there's some nice ideas popping up around the place.
I've understood the C++ principle of composition, which will allow for neater more sustainable code. In my mind there's some better idea's of how Luppp Automate reSampler etc need to be integrated into one larger program.
Also some messing about with a windows build has been done... apart from LibLO, and Pthreads I've got most of it sorted out. :-)
Next update after the exams! -Harry
Saturday, November 13, 2010
Luppp revived: reSampler
Hey,
I've just spent a lil while getting Luppp into a launchpad repo, and hacking the code a little in a small sub-project called reSampler.
Its gonna a mini JACK app that will scramble a .wav loop D'n'B style :-)
Hopefully Ill figure out how I actually want to control this little re-sampling program.
At the moment, I'm just concidering just a simple copy of say the 3rd part of an 8 part loop to the 5th part. An OSC interface in this case will be:
/resampler/load "sample.wav"
/resampler/setNumParts 8
/resampler/swap 3 5
/resampler/swaprev 3 5
swap just swaps the parts, swaprev, swaps & reverses the direction of the part.
I have a GTK widget that can draw files but it needs some optimization... It takes about 3 secs for a normal length loop atm.
More info on the way once I've got stuff implemented.
Cheers, -Harry
Clean drum looop
Same drum loop with reverb effect:
OSC interface has been implemented, can now swap parts around, reverse parts of the clip and revert to the original loop using ONLY OSC COMMANDS! :-)
I've just spent a lil while getting Luppp into a launchpad repo, and hacking the code a little in a small sub-project called reSampler.
Its gonna a mini JACK app that will scramble a .wav loop D'n'B style :-)
Hopefully Ill figure out how I actually want to control this little re-sampling program.
At the moment, I'm just concidering just a simple copy of say the 3rd part of an 8 part loop to the 5th part. An OSC interface in this case will be:
/resampler/load "sample.wav"
/resampler/setNumParts 8
/resampler/swap 3 5
/resampler/swaprev 3 5
swap just swaps the parts, swaprev, swaps & reverses the direction of the part.
I have a GTK widget that can draw files but it needs some optimization... It takes about 3 secs for a normal length loop atm.
More info on the way once I've got stuff implemented.
Cheers, -Harry
Clean drum looop
Same drum loop with reverb effect:
OSC interface has been implemented, can now swap parts around, reverse parts of the clip and revert to the original loop using ONLY OSC COMMANDS! :-)
Saturday, October 30, 2010
Automate: Another stage along the way!
Hey all,
Recently been quite busy hence the lack of posts, but today there's been an improvement in Automate. It actually works! :-)
It's quite a simple program, you input a MIDI Channel and CC, click in an automation line, and its gonna keep on repeating that line in CC's.
Mandatory Screenshot:
Currently you're to compile it yourself, but I'm looking into getting a PPA setup.
Ill keep yee up to date. :-)
-Harry
PS: This will be (publicly) announced & released eventually, for now it needs some reworking. (it sends its MIDI info every JACK frame, which is going to slow it down *a lot*.)
Recently been quite busy hence the lack of posts, but today there's been an improvement in Automate. It actually works! :-)
It's quite a simple program, you input a MIDI Channel and CC, click in an automation line, and its gonna keep on repeating that line in CC's.
Mandatory Screenshot:
Currently you're to compile it yourself, but I'm looking into getting a PPA setup.
Ill keep yee up to date. :-)
-Harry
PS: This will be (publicly) announced & released eventually, for now it needs some reworking. (it sends its MIDI info every JACK frame, which is going to slow it down *a lot*.)
Saturday, August 28, 2010
Summers over, projects on the go for the next months
Hey all,
Summer is almost over, the autumn is setting in, and I've had a break from programming on a regular basis. With new MIDI gear, fresh ideas, there's more reasons than ever to finish coding AutoMate.
Also my need for a very simple horizontal MIDI editor is being worked on, using most of the code base of the vala looping project. I do intend to (eventually) bring these projects together, but for now each needs to mature more before being integrated.
For now, I'm going to relax into the college year, and see how much coding-time I can take without things getting out of hand.. :-)
Cheers, -Harry
Summer is almost over, the autumn is setting in, and I've had a break from programming on a regular basis. With new MIDI gear, fresh ideas, there's more reasons than ever to finish coding AutoMate.
Also my need for a very simple horizontal MIDI editor is being worked on, using most of the code base of the vala looping project. I do intend to (eventually) bring these projects together, but for now each needs to mature more before being integrated.
For now, I'm going to relax into the college year, and see how much coding-time I can take without things getting out of hand.. :-)
Cheers, -Harry
Wednesday, July 28, 2010
Announce: PreHear *listen* to your samples
Hey all,
Its been a while, and I've been busy enough learning vala, writing
.vapi "binding" files, and just learning a bit more C in general.
But now for the fruit, a small handy little audio sample auditioner.
Currently it supports the JACK audio connection kit for audio output,
and will load any .wav, .au, or .aiff file you throw at it.
There are options as to play the whole file (play button),
play starting from position X (Play X), and to play from
position X, a duration of Y (Play X Y).
See attached screenshot for a "visual explaination".. and note the arrows
are a little sloppy.. I know! :-)
Getty link here: Link to Source Code download
Or get a built tarball here: Link to download
Cheers, -Harry
PS: Screenshot
Its been a while, and I've been busy enough learning vala, writing
.vapi "binding" files, and just learning a bit more C in general.
But now for the fruit, a small handy little audio sample auditioner.
Currently it supports the JACK audio connection kit for audio output,
and will load any .wav, .au, or .aiff file you throw at it.
There are options as to play the whole file (play button),
play starting from position X (Play X), and to play from
position X, a duration of Y (Play X Y).
See attached screenshot for a "visual explaination".. and note the arrows
are a little sloppy.. I know! :-)
Getty link here: Link to Source Code download
Or get a built tarball here: Link to download
Cheers, -Harry
PS: Screenshot
Labels:
GTKmm GUI programming,
JACK Audio Programming,
Vala
Saturday, June 26, 2010
Vala & Gstreamer
Hey All,
Yesterday I took the plunge to try and learn Vala. That's
not too bad as its based on C#, which has syntax like Java / C++.
Its a language designed around the GObject system that the Gnome
platform employs, and hence is a great language to use for that kind
of application development.
GStreamer (or GnomeStreamer..?) is a multimedia library that follows
the GObject style, and incorperates well with Vala & the Gnome platform.
All in all this should allow for "write-once, run-everywhere" programming,
while the performance should stay approximatly as good as when coding in
native C, because Vala gets compiled to C, and then the C sources are run
trough your C compiler of choice.. (gcc).
Ill let you know once I have something useful coded.. -Harry
Yesterday I took the plunge to try and learn Vala. That's
not too bad as its based on C#, which has syntax like Java / C++.
Its a language designed around the GObject system that the Gnome
platform employs, and hence is a great language to use for that kind
of application development.
GStreamer (or GnomeStreamer..?) is a multimedia library that follows
the GObject style, and incorperates well with Vala & the Gnome platform.
All in all this should allow for "write-once, run-everywhere" programming,
while the performance should stay approximatly as good as when coding in
native C, because Vala gets compiled to C, and then the C sources are run
trough your C compiler of choice.. (gcc).
Ill let you know once I have something useful coded.. -Harry
Thursday, June 24, 2010
Audio Experiences
Hey guys,
About time I actually posted what I'm working with. Its gonna be a long post, but it should provide an intresting piece, primarily because its all based on an Open Source Linux distro: Pure::Dyne.
So this is what me gear consists of:
Two Tapco S8 monitors, provide a good flat response.
They're surprisingly loud for 120W RMS per side, and in a small room the bass will shake you.
A Behringer B2092A subwoofer, 360 Watts RMS.. trough 2 8" backfacing cones in a semi-open design.. :-)
Driven by either the little
Phonic AM220 (left), or
the Soundcraft M12 (right).
Great thing about the M12 is it has direct-outs on each of the 12 channels. :-)
Witch are in turn fed signal by either the AudioFire 12, or the portable AudioFire 2.
Both do 24-96, but the AF12 goes right up to 192kHz...
The whole system is fed from an Acer TM 5720, which is a great laptop for Real Time work, as its got the firewire on the side, (Texas Instruments chip), and the Linux Kernel (2.6.x) recognizes it perfectly. This, teamed up with the FFADO firewire drivers for JACK, mean that there's a lot of audio possiblities around. :-)
On the "input" side, we've got the Akai LPD 8 midi controller (usb complaint), the Emu XBoard 61 (usb complaint too).
On the "fader side", there's a Frontier Design Alphatrack, which has support as an ALSA MIDI device trough a kernel module (bit of hassle, works well though).
The Software involved will be another post, But this is the hardware available to me at the moment.
Cheers, -Harry
About time I actually posted what I'm working with. Its gonna be a long post, but it should provide an intresting piece, primarily because its all based on an Open Source Linux distro: Pure::Dyne.
So this is what me gear consists of:
Two Tapco S8 monitors, provide a good flat response.
They're surprisingly loud for 120W RMS per side, and in a small room the bass will shake you.
A Behringer B2092A subwoofer, 360 Watts RMS.. trough 2 8" backfacing cones in a semi-open design.. :-)
Driven by either the little
Phonic AM220 (left), or
the Soundcraft M12 (right).
Great thing about the M12 is it has direct-outs on each of the 12 channels. :-)
Witch are in turn fed signal by either the AudioFire 12, or the portable AudioFire 2.
Both do 24-96, but the AF12 goes right up to 192kHz...
The whole system is fed from an Acer TM 5720, which is a great laptop for Real Time work, as its got the firewire on the side, (Texas Instruments chip), and the Linux Kernel (2.6.x) recognizes it perfectly. This, teamed up with the FFADO firewire drivers for JACK, mean that there's a lot of audio possiblities around. :-)
On the "input" side, we've got the Akai LPD 8 midi controller (usb complaint), the Emu XBoard 61 (usb complaint too).
On the "fader side", there's a Frontier Design Alphatrack, which has support as an ALSA MIDI device trough a kernel module (bit of hassle, works well though).
The Software involved will be another post, But this is the hardware available to me at the moment.
Cheers, -Harry
Wednesday, June 16, 2010
Tutorials!
Hey all,
After some recent activity on the Linux Audio Development mailing list,
I've decided to put all my Gtkmm Widgets, JACK MIDI examples etc into
repositories on Github.
Here's the links:
Gtkmm Custom Widgets
JACK MIDI Examples
Keep in mind that they're by no means "the professionals way to do it".
Also keep in mind that it does work on my machine here, any problems,
please report them back to me. :-)
Cheerio, till next, -Harry
After some recent activity on the Linux Audio Development mailing list,
I've decided to put all my Gtkmm Widgets, JACK MIDI examples etc into
repositories on Github.
Here's the links:
Gtkmm Custom Widgets
JACK MIDI Examples
Keep in mind that they're by no means "the professionals way to do it".
Also keep in mind that it does work on my machine here, any problems,
please report them back to me. :-)
Cheerio, till next, -Harry
Friday, May 14, 2010
General Progress
Hey,
I've been hacking away in the last month or so on various little projects, amongst them being Luppp, AutoMate, some OpenGL madness and a little Python scripting. Currently figuring out how to use Jack Midi, of which the first tests worked out today...
Exams are almost over, and the Irish summer is about to kick in... :-) Hopefully Ill get the opportunity to keep hacking on Luppp, I feel that its getting somewhere fun...
Also on me todo list is Arduino promotion, I'm going to get the Ethernet shield at some point, and use it to control Luppp via OSC. This should prove to be entrataining to build & use, hope that its gonna be easy!
-Harry
I've been hacking away in the last month or so on various little projects, amongst them being Luppp, AutoMate, some OpenGL madness and a little Python scripting. Currently figuring out how to use Jack Midi, of which the first tests worked out today...
Exams are almost over, and the Irish summer is about to kick in... :-) Hopefully Ill get the opportunity to keep hacking on Luppp, I feel that its getting somewhere fun...
Also on me todo list is Arduino promotion, I'm going to get the Ethernet shield at some point, and use it to control Luppp via OSC. This should prove to be entrataining to build & use, hope that its gonna be easy!
-Harry
Wednesday, April 14, 2010
Luppp: Update 4
Hey,
Lots of time has passed since the last update, here's the latest.
Till next, -Harry
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
Monday, February 22, 2010
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
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
Tuesday, February 9, 2010
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
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
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
Saturday, February 6, 2010
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
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
Friday, January 22, 2010
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
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
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
Wednesday, January 6, 2010
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
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
Subscribe to:
Posts (Atom)