On 17 August 2010 00:54, Philipp Überbacher <hollunder(a)lavabit.com> wrote:
> Excerpts from James Morris's message of 2010-08-15 03:21:38 +0200:
>> On 5 July 2010 09:27, Patrick Shirkey <pshirkey(a)boosthardware.com> wrote:
>> > On 07/05/2010 06:15 PM, James Morris wrote:
>> >>
>> >> really it is far too early for users to take any interest in this
>> >> program. but sometimes I just need some feedback about some of the
>> >> ideas i have before I can proceed further in its development.
>> >>
>> >>
>> >>
>> >
>> >
>> > I think LAU/LAD are good for that until a project gets a large enough user
>> > base to warrant it's own list.
>> >
>>
>> Ok, after some considerable time it's now in the first steps of having
>> consequences of user interactions...
>>
>> Meaning, you can drag a blue square around and the events in the
>> pattern are sequenced into it (when you release the mouse button that
>> is). As you should by now know, the position of the events is
>> translated into pitch and velocity.
>>
>> It's enough to play around with for a few minutes :)
>>
>> I recommend Will J Godfrey's 'Sweep Saw' Zyn/Yoshi patch.
>>
>> Try it out:
>> git clone git://github.com/jwm-art-net/BoxySeq.git && cd BoxySeq &&
>> make && ./boxyseq
>>
>>
>> Just don't expect too much. You cannot edit the pattern unless you're
>> willing to experiment with C code (lines 63 to 84 of main.c for event
>> pattern, lines 87 to 105 for boundary settings) and recompile and
>> restart the program.
>>
>> you'll need jack, glib, and gtk development packages installed beforehand.
>>
>> still very early days here.
>>
>> Cheers,
>> James.
>
> Hey James.
> I'm just giving it a try, and it's fun. I found a feature you didn't
> tell us about, rightclick+drag to resize/reshape the box.
> I gave three different zynaddsubfx/yoshimi patches a try, and it's fun
> with all of them. I can imagine that it's already useful, at least for
> adding random bleeps or whatever to pieces.
>
> Nice work so far.
> Regards,
> --
> Philipp
Hi, thanks for your comments. Yes I added the resize the following day.
The CPU usage of the graphics has been bothering me. It was using
Cairo which can do some funky stuff, but it comes at a price. My
latest commit has removed the Cairo code and replaced it with GDK. GDK
is 'closer to xlib' and is less funky, but performance is much better.
This version is using two boundaries fed by a single pattern.
I need some ideas about the user interface. The way you can manipulate
the boundary box positions and dimensions around is good. But I'd like
the user to also be able to change the scale and key of the events
placed within the boundary with as much ease.
Being able to make selections will be important too.
Though I imagine there's going to be a whole lot of icons with boxes on them!
An icon to make selections
An icon to define a boundary
An icon to redefine a boundary (repositon+redimension in one foul swoop)
An icon to define a block (a block blocks events from being placed where it is)
very boxy indeed.
Cheers,
James.
On Sun, Aug 15, 2010 at 4:29 PM, Daniel Worth <pipemanmusic(a)gmail.com> wrote:
> Awesome work, I'm very happy to see some work going into this.
Thanks! There's more coming... (the version i'm using now is
http://lalists.stanford.edu/lad/2010/08/0059.html , a patch to
http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz ).
> Why is the adjustment for the
> DAC/ADC's on a different tab from the monitor/VU meters. It is an utter PIA
> to set levels by switching back a forth from one tab to another. I know it's
> how the windows gui handled it but IMHO it sucks.
We're discussing this very thing on Linux-Audio-Dev (see link above),
so I've cc'd the ongoing discussions using the same Subject line we've
been using.... (your original cc to Linux-audio-announce is going to
bounce; I took the liberty to redirect your cc to the appropriate
list).
-- Niels
http://nielsmayer.com
On 5 July 2010 09:27, Patrick Shirkey <pshirkey(a)boosthardware.com> wrote:
> On 07/05/2010 06:15 PM, James Morris wrote:
>>
>> really it is far too early for users to take any interest in this
>> program. but sometimes I just need some feedback about some of the
>> ideas i have before I can proceed further in its development.
>>
>>
>>
>
>
> I think LAU/LAD are good for that until a project gets a large enough user
> base to warrant it's own list.
>
Ok, after some considerable time it's now in the first steps of having
consequences of user interactions...
Meaning, you can drag a blue square around and the events in the
pattern are sequenced into it (when you release the mouse button that
is). As you should by now know, the position of the events is
translated into pitch and velocity.
It's enough to play around with for a few minutes :)
I recommend Will J Godfrey's 'Sweep Saw' Zyn/Yoshi patch.
Try it out:
git clone git://github.com/jwm-art-net/BoxySeq.git && cd BoxySeq &&
make && ./boxyseq
Just don't expect too much. You cannot edit the pattern unless you're
willing to experiment with C code (lines 63 to 84 of main.c for event
pattern, lines 87 to 105 for boundary settings) and recompile and
restart the program.
you'll need jack, glib, and gtk development packages installed beforehand.
still very early days here.
Cheers,
James.
Does anyone know of (or is there interest in creating) a
library of basic, low-level, audio mixing subroutines? This
would be analag to the BLAS[1], but for audio.
What I'm thinking is something like Ardour's SSE-optimized
mixing subroutines... and updating it for later
optimizations (SSE2, SSE3, ...).
Thanks,
Gabriel
[1] http://www.netlib.org/blas/
Fons just wrote "as far as i'm concerned, it would be cool to have
some help creating a "hybrid" matrix like i described to bearcat, to
avoid having to run separate ambdecs for tops and subs. the most
important thing would be another gain coefficient to match the subs to
the tops, similar to what you already have to tweak the two
psychoacoustic bands."
gain coefficient....what? I know that makes sense to the lot of you but
not to me. I'd like to fix that.
I love sound and i'm genuinely interested in sound theory, audio
recording, the effects of sound on the body and ambisonics. My problem
is that some of the things said on this list come across as Frontier
Gibberish because though i have the background in it as a hobby i don't
have the training or education (mine is in computer programming not
audio). Reading up on ambisonics lots of it is technical and i'd like
to be able to understand it.
So i want to educate myself. Does anyone have any suggestions for books
or what have you that i could pick up to give me a basic feel for how
all this works, basic accoustic sound theory? Should i pick up a book on
algebra 2 first? (i'm not a math-wiz. I finally passed Algebra 1 on the
2nd try). If i were to look at a college course for what books they
use, what course titles would i be looking for?
I probably won't get to the knowledge level of Fons or Jorn by reading
books an messing around with my equipment, but i'd sure like to try.
For what it's worth English is my first and last language when talking
about reading material.
Thanks folks. I appreciate it.
Hi Guys, I'm proud to announce my first project on gitorious:
TerminatorX. I took the code from the old project site, and have done
some heavy recoding:
The entire audio part: -Now tX relies exclusively on JACK, and I intend
to keep it so.
-New mixer behind the scene: All
Turntables are stereo, you can still load mono files and the stream will
be copied to the left and right. This is intentional, since it allows to
use stereo Plugins on mono files (some sweet LADSPA plugins are only i
stereo).
-Mono plugins are also usable, their output is simply doubled
-Extra stereo outputs per Turntable
-Support for Rubberband, tempo of
client turntables can be autosynced to the master turntable.
- Exclusive use of sndfile
-Rewriting of the sequencer part,
not all is functional
There is lots to do: -profiling, since tX crashes sometimes (actually
many times:))
- throw out old C code, where its
possible: tX relies on C-style Gtk, which is a pain in the neck for a C
++ programmer like me.
- there are many C-extern functions. To
hell with them, they are bad coding style.
- the gui still displays one channel,
also for stereo files.
- the sequencer has to be checked,
fixed. I actually would like to redesign it, but more later.
- the save and load routines have to be
checked, since I added some parameters which are not yet saved/loaded
All in all tX needs a redesign in 3 integral parts,ordered by priority:
-The sequencer (tX_seqpar) is a mess. I even didn't really bother to
look that deep into the code. As I understand it, it just records
changes of the parameters, then replays them. I think this could be done
easier, and in strict C++ style. I need some ideas on how to construct a
good model.
-The Load and Save routines: I would like to convert all classes to
serializable ones!! This is more transparent, and would allow for nice
things like network sessions (Imagine tX on multiple PCs running with
netjack, and saving the session to one instance on one PC!)
-Last but by far not least: The GUI. If you look at the code, you see
that Alexander did not make a clear line between the GUI and the engine.
I think this is important, for stability reasons. Second, its C-Style
Gtk and not portable.
So the plan is to open another branch, in order to rework the GUI so
that a) It is at least codewise seperated from the engine (e.g extra
namespaces).
b) It's pure C++ and c) its portable. I think the only choice there is,
is to switch to Qt, but I'll leave that open for discussion.
So hope you get in and grab the code at
http://gitorious.org/terminatorx . Theres no configscript, you have to
change the makefile to you needs.
Lets revive this wonderfull program.
Gerald
P.S Sorry for the poor documentation !!
On Wed, 2010-08-11 at 09:09 +1000, Geoff Beasley wrote:
> boyz,
>
> as a longtime user of multiple ice1712 cards (4) in a 'multi' array, one
> thing envy24contol never offered was a way of "assembling" or even
> seeing multiple cards from within a single instance. You can of course
> address different cards with the -c option, but it would make sense if
> this could be done within the a single instance; and given that it
> writes it's own config/.asoundrc type file then would it be possible for
> mudita24 to create a multi card array easily?
>
> i have always, like John Rigg, made my own .asoundrc(thanks John!) to
> run the alsa multi plug which just runs at boot, but this can be very
> difficult for the neebie to even understand let alone create themselves
> and it would be good if each card had it's own 'page' for tweaking and
> metering within a single app instance. whilst you're doing this fine
> work I thought I'd chime this in.
>
> 2c
>
> g.
You're referring to http://www.jrigg.co.uk/linuxaudio/ice1712multi.html?
I'm new to the multiple Envy24 cards world, since some weeks I've got a
second card, but I also had a time out.
Full ACK.
+2c
Ralf
Hi Guys, I'm proud to announce my first project on gitorious:
TerminatorX. I took the code from the old project site, and have done
some heavy recoding:
The entire audio part: -Now tX relies exclusively on JACK, and I intend
to keep it so.
-New mixer behind the scene: All
Turntables are stereo, you can still load mono files and the stream will
be copied to the left and right. This is intentional, since it allows to
use stereo Plugins on mono files (some sweet LADSPA plugins are only i
stereo).
-Mono plugins are also usable, their output is simply doubled
-Extra stereo outputs per Turntable
-Support for Rubberband, tempo of
client turntables can be autosynced to the master turntable.
- Exclusive use of sndfile
-Rewriting of the sequencer part,
not all is functional
There is lots to do: -profiling, since tX crashes sometimes (actually
many times:))
- throw out old C code, where its
possible: tX relies on C-style Gtk, which is a pain in the neck for a C
++ programmer like me.
- there are many C-extern functions. To
hell with them, they are bad coding style.
- the gui still displays one channel,
also for stereo files.
- the sequencer has to be checked,
fixed. I actually would like to redesign it, but more later.
- the save and load routines have to be
checked, since I added some parameters which are not yet saved/loaded
All in all tX needs a redesign in 3 integral parts,ordered by priority:
-The sequencer (tX_seqpar) is a mess. I even didn't really bother to
look that deep into the code. As I understand it, it just records
changes of the parameters, then replays them. I think this could be done
easier, and in strict C++ style. I need some ideas on how to construct a
good model.
-The Load and Save routines: I would like to convert all classes to
serializable ones!! This is more transparent, and would allow for nice
things like network sessions (Imagine tX on multiple PCs running with
netjack, and saving the session to one instance on one PC!)
-Last but by far not least: The GUI. If you look at the code, you see
that Alexander did not make a clear line between the GUI and the engine.
I think this is important, for stability reasons. Second, its C-Style
Gtk and not portable.
So the plan is to open another branch, in order to rework the GUI so
that a) It is at least codewise seperated from the engine (e.g extra
namespaces).
b) It's pure C++ and c) its portable. I think the only choice there is,
is to switch to Qt, but I'll leave that open for discussion.
So hope you get in and grab the code at
http://gitorious.org/terminatorx . Theres no configscript, you have to
change the makefile to you needs.
Lets revive this wonderfull program.
Gerald
P.S Sorry for the poor documentation !!