1 Jul
2010
1 Jul
'10
10:54 p.m.
Hi,
I'm working on a new MIDI app which shares some features with a
sequencer, but in other ways is more like an arpeggiator, but also
somewhat different to both.
It's like a sequencer in that the user will be able to create rhythmic
patterns which lack pitch and velocity data, and almost like an
arpeggiator in that it will automatically generate the pitch and
velocity data from an algorithm - and unlike either a sequencer or
arpegiattor, it uses a 2d window-placement like algorithm to generate
pitch/velocity (mapping these to x/y).
Basically, I am after opinions from a potential users on the following:
1) a basic 'timebase master' implementation which lacks tempo maps,
signature changes, etc, just enough to fire the app up and play around
with ideas (currently it does this).
2) no timebase master at all, (just like arpage), you must have some
other sequencer running.
3) a full feature time base master with tempo/meter changes etc.
The case for 1 is just as it says, ease of use for playing around
with, and only for playing around with.
The user would be expected to run a fully featured sequencer/daw for
features such as tempo and meter changes.
Would having 1) just confuse users? (but if they're confused by that...)
The case against 3 is other apps like ardour, rosegarden, already do
this, and probably better than I can get my app to.
Cheers,
James.
1 Jul
1 Jul
11:02 p.m.
James,
On Thu, 1 Jul 2010, James Morris wrote:
I'm working on a new MIDI app which shares some
features with a
sequencer, but in other ways is more like an arpeggiator, but also
somewhat different to both.
Do you have a link to your current code?
I've been meaning to try this... but the description always
sounds like "experimental sequencer that will spam your
desktop with lots of pop-up windows." -- so I've put it off.
I promise to try it this time. :-)
-gabriel
11:22 p.m.
On 1 July 2010 22:02, Gabriel M. Beddingfield <gabrbedd(a)gmail.com> wrote:
James,
On Thu, 1 Jul 2010, James Morris wrote:
Ah, well the "spam your desktop with lots of pop-up windows" days are over now.
It's currently in the "i demand an xterm at least 128 x 128 in size
but i still can't do anything you might want me to do" stage.
I'm only working on the backend at the moment, and that's half
complete, but just beginning to output MIDI now.
http://github.com/jwm-art-net/BoxySeq
just to re-iterate: it's not usable.
I'm working on a new MIDI app which shares
some features with a
sequencer, but in other ways is more like an arpeggiator, but also
somewhat different to both.
Do you have a link to your current code?
I've been meaning to try this... but the description always sounds like
"experimental sequencer that will spam your desktop with lots of pop-up
windows." -- so I've put it off. 
11:15 p.m.
On Thu, 1 Jul 2010 21:54:19 +0100
James Morris <james(a)jwm-art.net> wrote:
Hi,
I'm working on a new MIDI app which shares some features with a
sequencer, but in other ways is more like an arpeggiator, but also
somewhat different to both.
It's like a sequencer in that the user will be able to create rhythmic
patterns which lack pitch and velocity data, and almost like an
arpeggiator in that it will automatically generate the pitch and
velocity data from an algorithm - and unlike either a sequencer or
arpegiattor, it uses a 2d window-placement like algorithm to generate
pitch/velocity (mapping these to x/y).
Basically, I am after opinions from a potential users on the following:
1) a basic 'timebase master' implementation which lacks tempo maps,
signature changes, etc, just enough to fire the app up and play around
with ideas (currently it does this).
2) no timebase master at all, (just like arpage), you must have some
other sequencer running.
3) a full feature time base master with tempo/meter changes etc.
The case for 1 is just as it says, ease of use for playing around
with, and only for playing around with.
The user would be expected to run a fully featured sequencer/daw for
features such as tempo and meter changes.
Would having 1) just confuse users? (but if they're confused by that...)
The case against 3 is other apps like ardour, rosegarden, already do
this, and probably better than I can get my app to.
Cheers,
James.
Sounds interesting. I would describe it as an 'Intelligent
Arpeggiator'.
Options 1 + 2 look most interesting. As you suggest, 1 for fiddling
about with ideas, 2 for actually producing a finished, linked work.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
2 Jul
2 Jul
1:57 a.m.
On Thu, 1 Jul 2010, James Morris wrote:
It's like a sequencer in that the user will be
able to create rhythmic
patterns which lack pitch and velocity data, and almost like an
arpeggiator in that it will automatically generate the pitch and
velocity data from an algorithm - and unlike either a sequencer or
arpegiattor, it uses a 2d window-placement like algorithm to generate
pitch/velocity (mapping these to x/y).
The more I think about this... the more fun it sounds.
Have you considered doing an MDI interface? This way you
can go back to spamming windows... but it stays contained in
your applications MainWindow.
1) a basic 'timebase master' implementation
which lacks tempo maps,
signature changes, etc, just enough to fire the app up and play around
with ideas (currently it does this).
When you say 'timebase master' -- do you mean Jack's
timebase master? Or internal.
I'm invisioning something very simple and flexible.
Something that pretty much keeps 1/4 time. Something that
can also slave to the Jack transport.
However, I think if you try to make this into something that
can be a reliable Jack transport master -- I think it would
stop being fun. :-)
Peace,
Gabriel
6:12 a.m.
On 2 July 2010 00:57, Gabriel M. Beddingfield <gabrbedd(a)gmail.com> wrote:
master of the timebase, for jack clients?
On Thu, 1 Jul 2010, James Morris wrote:
No I'd not considered it. But as long as I could force the doc windows
to appear exactly where told it would work but this would probably
depend upon whichever window-manager was controlling windows. I'm not
keen.
It's like a sequencer in that the user will
be able to create rhythmic
patterns which lack pitch and velocity data, and almost like an
arpeggiator in that it will automatically generate the pitch and
velocity data from an algorithm - and unlike either a sequencer or
arpegiattor, it uses a 2d window-placement like algorithm to generate
pitch/velocity (mapping these to x/y).
The more I think about this... the more fun it sounds.
Have you considered doing an MDI interface? This way you can go back to
spamming windows... but it stays contained in your applications MainWindow. 1) a basic
'timebase master' implementation which lacks tempo maps,
signature changes, etc, just enough to fire the app up and play around
with ideas (currently it does this).
When you say 'timebase master' -- do you mean Jack's timebase master? Or
internal. I'm invisioning something very simple and
flexible. Something that pretty
much keeps 1/4 time. Something that can also slave to the Jack transport.
If doing that prevented me as a user from using it with more
interesting time signatures than 4/4 I'd be pretty hacked off.
However, I think if you try to make this into
something that can be a
reliable Jack transport master -- I think it would stop being fun. :-)
Yeah, I could make it really complicated..
Cheers,
James.
Peace,
Gabriel
7:11 a.m.
On Fri, 2 Jul 2010, James Morris wrote:
AFAIK, the windows inside the app are not controlled by the
window manager at all. You would have full control.
Really, I was thinking about allowing mismatched time
signatures while still having the transport "keep the beat."
For example, each window generates patterns in different
time signatures at the same time (4/4, 5/4, 7/8, etc.). If
your transport is simply "keeping a beat" (1/4) then it's
easy to do this.
But if your transport is keeping 4/4 time... getting 5/4 and
7/8 to sync along isn't quite as simple.
Why would anyone want to do this? A good example is 'Let
Down' by Radiohead (from OK Computer). The bell/guitar
intro is in some strange meter. The band comes in with a
4/4 time... and the way tha the bell/guitar part syncs is
(IMHO) just plain interesting to listen to.
-gabriel
Have you
considered doing an MDI interface? This way you can go back to
spamming windows... but it stays contained in your applications MainWindow.
No I'd not considered it. But as long as I could force the doc windows
to appear exactly where told it would work but this would probably
depend upon whichever window-manager was controlling windows. I'm not
keen. I'm
invisioning something very simple and flexible. Something that pretty
much keeps 1/4 time. Something that can also slave to the Jack transport.
If doing that prevented me as a user from using it with more
interesting time signatures than 4/4 I'd be pretty hacked off.
3:47 p.m.
On 2 July 2010 06:11, Gabriel M. Beddingfield <gabrbedd(a)gmail.com> wrote:
On Fri, 2 Jul 2010, James Morris wrote:
AFAIK, the windows inside the app are not controlled by the window manager
at all. You would have full control.
Really, I was thinking about allowing mismatched time signatures while still
having the transport "keep the beat."
For example, each window generates patterns in different time signatures at
the same time (4/4, 5/4, 7/8, etc.). If your transport is simply "keeping a
beat" (1/4) then it's easy to do this.
But if your transport is keeping 4/4 time... getting 5/4 and 7/8 to sync
along isn't quite as simple.
It is currently initialized to 4/4 time but the intent is there to
allow any meter.
Have you
considered doing an MDI interface? This way you can go back to
spamming windows... but it stays contained in your applications
MainWindow.
No I'd not considered it. But as long as I could force the doc windows
to appear exactly where told it would work but this would probably
depend upon whichever window-manager was controlling windows. I'm not
keen. I'm
invisioning something very simple and flexible. Something that pretty
much keeps 1/4 time. Something that can also slave to the Jack
transport.
If doing that prevented me as a user from using it with more
interesting time signatures than 4/4 I'd be pretty hacked off.
Why would anyone want to do this? A good example is 'Let Down' by Radiohead
(from OK Computer). The bell/guitar intro is in some strange meter. The
band comes in with a 4/4 time... and the way tha the bell/guitar part syncs
is (IMHO) just plain interesting to listen to.
Ah I see. That makes sense. Not sure if you looked at the code or not,
but I have put provisions in for the patterns to have their own time
signature, as it is something I'm interested in experimenting with.
Still it raises some questions. This is fine if the app is timebase
master, then 1/4 time is guarantee-able, otherwise, the not quite so
simple approach to syncing 5/4 and 7/8 would be required.
It is something I've been wondering about without necessarily thinking
about syncing 5/4 and 7/8 together.
If in the app a pattern is edited with a 5/4 meter and the pattern is
precisely 1 bar long (ie 5 quarter notes right!?!?) then what if the
transport is playing at 4/4? Should the last beat in the 5/4 loop be
dropped, or should it just offset the start of the 5/4 loop each time?
Cheers,
James.
-gabriel
5:42 p.m.
On Fri, 2 Jul 2010, James Morris wrote:
Still it raises some questions. This is fine if the
app is timebase
master, then 1/4 time is guarantee-able, otherwise, the not quite so
simple approach to syncing 5/4 and 7/8 would be required.
If the app is the timebase slave... you just translate
the "system" transport to your simple 1/4 transport.
It's very simple to map any time signature to 1/4.
It is something I've been wondering about without
necessarily thinking
about syncing 5/4 and 7/8 together.
If in the app a pattern is edited with a 5/4 meter and the pattern is
precisely 1 bar long (ie 5 quarter notes right!?!?) then what if the
transport is playing at 4/4? Should the last beat in the 5/4 loop be
dropped, or should it just offset the start of the 5/4 loop each time?
That depends on the application. If you are taking pre-made
clips and throwing them together into some kind of remix...
then truncating the pattern makes sense:
4/4: 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
5/4: 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
7/8: 1234567 1234567 1234567 1234567
Examples: EnergyXT, Hydrogen(?)
However, if you're an experimental sequencer pumping out
semi-random patterns based on the size and placement of
boxes on an xterm... I think overlapping patterns makes
sense:
4/4: 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
5/4: 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
7/8: 1234567123456712345671234567
Example: Seq24, non-sequencer(?)
-gabriel
12:46 p.m.
Excerpts from Gabriel M. Beddingfield's message of 2010-07-02 01:57:17 +0200:
On Thu, 1 Jul 2010, James Morris wrote:
Since most window managers support a 'workspace' concept I guess it's
not a big deal. But who uses xterm? :) And fixed size? What about tiling
window managers?
Actually I have no idea how this will work, but it sounds like it could
be fun.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
It's like a sequencer in that the user will
be able to create rhythmic
patterns which lack pitch and velocity data, and almost like an
arpeggiator in that it will automatically generate the pitch and
velocity data from an algorithm - and unlike either a sequencer or
arpegiattor, it uses a 2d window-placement like algorithm to generate
pitch/velocity (mapping these to x/y).
The more I think about this... the more fun it sounds.
Have you considered doing an MDI interface? This way you
can go back to spamming windows... but it stays contained in
your applications MainWindow.
3:37 p.m.
On 2 July 2010 11:46, Philipp Überbacher <hollunder(a)lavabit.com> wrote:
Excerpts from Gabriel M. Beddingfield's message of
2010-07-02 01:57:17 +0200:
The window placement algorithm is done, and I spent quite some time
getting it working satisfactorily performance-wise, within real time
constraints. The idea is based upon window-manager window-placement,
but in the distant future - when the app is up and running with a nice
shiny GUI - the user might not ever care nor need to care, that the
boxes that appear simultaneously as notes are played is based upon
window-manager window-placement. I don't think it will be necessary to
place much emphasis on it's origins. It's only that way right now
because I've not evolved my thinking about how to describe it further
than "it's like a window-manager's window-placement" :-)
And what are you referring to as fixed size?
Cheers,
james.
On Thu, 1 Jul 2010, James Morris wrote:
Since most window managers support a 'workspace' concept I guess it's
not a big deal. But who uses xterm? :) And fixed size? What about tiling
window managers? It's like a sequencer in that the user will
be able to create rhythmic
patterns which lack pitch and velocity data, and almost like an
arpeggiator in that it will automatically generate the pitch and
velocity data from an algorithm - and unlike either a sequencer or
arpegiattor, it uses a 2d window-placement like algorithm to generate
pitch/velocity (mapping these to x/y).
The more I think about this... the more fun it sounds.
Have you considered doing an MDI interface? This way you
can go back to spamming windows... but it stays contained in
your applications MainWindow.
5351
days inactive
5352
days old
linux-audio-user@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Folderol -
Gabriel M. Beddingfield -
James Morris -
Philipp Überbacher