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
Monday, February 22, 2010
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
Subscribe to:
Posts (Atom)