30 Aug
2007
30 Aug
'07
3:36 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
WARNING: this is harsh and pretty much unlistenable-- and certainly unmusical--, but I
find it hilariously funny:
http://www.restivo.org/misc/moltar-atrocity-0.1.ogg
I modified a PD sample-mangling patch, attached MIDI CC's to some of its parameters,
loaded it up with a sample from a classic "Space Ghost" episode, and spent a few
minutes of gleeful insanity tweaking MIDI faders.
Not only is it a sonic atrocity, but it's also a legal atrocity: there's no way
I'd ever be able to clear the rights to this from Cartoon Network, so I'll take
this down after a few days.
Serious question: what do y'all do about the 1980's-era idiocy of MIDI, in that it
only has 127 steps in its CC's (sheesh, not even a lousy byte!). Do you burn two
controllers with fine/coarse adjustments? If so, how do you determine the scale for fine
and/or coarse?
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG1lcpe8HF+6xeOIcRAk9QAJ93vfk3uFC5t1beY+DFvxyD73hAPQCfR4+q
45AHmIbP8lS7+Uxk357bsHk=
=ykC0
-----END PGP SIGNATURE-----
30 Aug
30 Aug
5:38 a.m.
On Wed, Aug 29, 2007 at 10:35:37PM -0700, Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
WARNING: this is harsh and pretty much unlistenable-- and certainly
unmusical--, but I find it hilariously funny:
http://www.restivo.org/misc/moltar-atrocity-0.1.ogg
Yes to "unmusical". However, it sounds like this technique could be
used to make a sample "sing" in more structured ways.
Even here, there are many sections that one could cut out to arrange
them and get somewhere :)
--
Thorsten Wilms
Thorwil's Design for Free Software:
http://thorwil.wordpress.com
6:25 a.m.
Am Donnerstag, 30. August 2007 schrieb Thorsten Wilms:
On Wed, Aug 29, 2007 at 10:35:37PM -0700, Ken Restivo
wrote:
Yeah! Remixing the remix?!
Arnold
--
visit http://www.arnoldarts.de/
---
Hi, I am a .signature virus. Please copy me into your ~/.signature and send me
to all your contacts.
After a month or so log in as root and do a rm / -rf. Or ask your
administrator to do so...
WARNING: this is harsh and pretty much
unlistenable-- and certainly
unmusical--, but I find it hilariously funny:
http://www.restivo.org/misc/moltar-atrocity-0.1.ogg
Yes to "unmusical".
However, it sounds like this technique could be
used to make a sample "sing" in more structured ways.
Even here, there are many sections that one could cut out to arrange
them and get somewhere :) 
7:16 a.m.
>Serious question: what do y'all do about the
1980's-era idiocy of MIDI, in
that it only has 127 steps in its CC's
(sheesh, not even a lousy byte!). Do
you burn two controllers with fine/coarse adjustments? If so, how do you
determine the scale for fine and/or coarse?<<
one thing i have done in pd is turn my midi controller into an accelerator.
it's a bit different to use, but is really good for filter sweeps and stuff
like that.
quick explanation:
1) scale the midi data into a nice curve between -1 and 1
[ctlin]
|
[- 64]
|
[/ 64]
|
[expr pow($f1, 3)]
2) add a flat spot in the middle of the curve so that midi data between 55
->75 will cause zero acceleration
[* 100]
|
[div 100]
|
[/ 100]
3) use this acceleration data to feed a counter
(bit hard to draw here, so see attached patch)
7:39 a.m.
New subject: An atrocity committed with PD (MIDI Spec)
1980's-era idiocy of MIDI, in that it only has 127
steps in its CC's (sheesh, not even a lousy byte!). Do you burn two controllers with
fine/coarse adjustments? If so, how do you determine the scale for fine and/or coarse?>
The choice to use 7 bit rather than 8 bit transmission in the original spec was pragmatic.
If 8 bit had been used it would have added more than 10% of useless overhead to realtime
messages (key on/off) and not really have improved the efficiency of other controls - 127
steps are too restrictive, but 256 would have been as well so double encoding would still
have been a requirement. At the time, this overhead was quite a lot with a tranmission
rate of just 31.25 Kb/s, and the use of more complex encoding would have been an effort
for the 8 bit processors used in the early synths for which this was developed.
A vast number of the controllers are already linked up to fine/coarse, some of which have
definitions regarding functionality, especially for tuning features. There is also the Non
Registered Parameter feature that extends the number of continuous fine/coarse controllers
to 14bits (16K resolution) at the expense of a few extra messages using the Data Entry CC.
The extra messages do not necessarily add much further latency since few people actually
run MIDI over MIDI cables - MIDI/USB and MIDI/FW are more common these days, the small
MIDI messages running 200Mb/s plus is very little latency.
That is not to say there are not issues with Midi. It is difficult to get hold of all the
diverse submitted alterations to the original spec, for example, without membership of the
Midi Manufacturers Association. SYSEX messages only take members' registered IDs.
There is one experimental sysex ID for schools and non-commercial use (see below) but
beyond that a developer has to request a registered ID from the MMA to have garanteed
interoperable sysex. I think its only $200 per year, however if you are writing a freeware
app that could be a lot of lost meals. The lack of sysex for non-commercial use limits
functionality. Most useful features have already been integrated into the spec without
SYSEX however bulk dumping of device specific data is pretty much not possible. The use of
the single '0x7D' non-commercial ID is restrictive, its a single number so it
cannot be used to support sysex to multiple softsynths on the same midi bus - they could
not tell who was to respond to the message, and they are also specified not to be used
publicly, ie, if you implement it then you should not be placed on the same bus as a
commercial product.
I don't think its really time for another spec, OSC is available, and MIDI has
functioned and scaled pretty well over the last 20 years, its extremely widely deployed
and is the standard since everybody implements it, even though it is not exactly open. I
would like to see the 0x7D non-commerical sysex being hijacked though. A minimal extra
layer of syntax on top of it would allow an open authority to deliver free IDs to open
source and freeware programmes allowing them a reliable data exchange over this medium, it
would just require that the first 3 or 4 bytes of an 0x7D sysex be used as another
application identifier.
Nick.
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
9:09 a.m.
New subject: An atrocity committed with PD (MIDI Spec)
Nick Copeland wrote:
The choice to use 7 bit rather than 8 bit transmission in the original
spec was pragmatic. If 8 bit had been used it would have added more
than 10% of useless overhead to realtime messages (key on/off) and not
really have improved the efficiency of other controls - 127 steps are
too restrictive, but 256 would have been as well so double encoding
would still have been a requirement. At the time, this overhead was
quite a lot with a tranmission rate of just 31.25 Kb/s, and the use of
more complex encoding would have been an effort for the 8 bit processors
used in the early synths for which this was developed.
There was a lot less horsepower running around in those days. Especially
since the one processor also had to exercise real-time control over the
music hardware while sending, receiving and (I guess) passing through
MIDI events. The standard MIDI port is basically just a serial port, so
if 31.25Kb/s was the speed, that was pretty fast for those days.
I am curious - has there been any move to modernize the MIDI
connectivity standards to include USB or Ethernet?
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
1980's-era
idiocy of MIDI, in that it only has 127 steps in its CC's
(sheesh, not even a
lousy byte!). Do you burn two controllers with
fine/coarse adjustments? If so, how do you determine the scale for fine
and/or coarse?
9:44 a.m.
New subject: An atrocity committed with PD (MIDI Spec)
I am curious - has there been any move to modernize
the MIDI
connectivity standards to include USB or Ethernet?
There has been - there is a midi over usb standard.
Midi is a poor starting point for modernisation not just beacause of
the pragmatic compromises mentioned above but also because it is
wholly unlayered (the spec covers everything from the physical up to
the presentational layer), and has it's expansion room squeezed into
the SysEx ghetto. Midi over ethernet would be even less pleasant, and
less logical, than doing RS-232 over ethernet.
OSC has fixed these problems and should have been built into
everything since the mid-90s but so many people have invested time in
learning MIDI that they wouldn't countenance working with anything
else. It looks like RESTful web services may eventually replace both,
however.
--
steev
http://www.daikaiju.org.uk/~steve/
9:52 a.m.
New subject: An atrocity committed with PD (MIDI Spec)
On Thu, 30 Aug 2007 12:43:15 +0100
"Steve McConville" <mcconville.steve(a)gmail.com> wrote:
I can't help thinking there is also an element of 'if it aint broke
don't fix it'.
This is true for me. MIDI does everything I want without significant
problems OUTSIDE my computer, and once inside, it becomes largely
irrelevant.
--
Will J Godfrey
http://www.musically.me.uk
I am curious -
has there been any move to modernize the MIDI
connectivity standards to include USB or Ethernet?
There has been - there is a midi over usb standard.
Midi is a poor starting point for modernisation not just beacause of
the pragmatic compromises mentioned above but also because it is
wholly unlayered (the spec covers everything from the physical up to
the presentational layer), and has it's expansion room squeezed into
the SysEx ghetto. Midi over ethernet would be even less pleasant, and
less logical, than doing RS-232 over ethernet.
OSC has fixed these problems and should have been built into
everything since the mid-90s but so many people have invested time in
learning MIDI that they wouldn't countenance working with anything
else. It looks like RESTful web services may eventually replace both,
however. 
2 Sep
2 Sep
1:58 p.m.
New subject: An atrocity committed with PD (MIDI Spec)
Hallo,
Folderol hat gesagt: // Folderol wrote:
I can't help thinking there is also an element of
'if it aint broke
don't fix it'.
This is true for me. MIDI does everything I want without significant
problems OUTSIDE my computer, and once inside, it becomes largely
irrelevant.
I like this view by Max/Pd inventor Miller S. Puckette:
Q: "Do you think the MIDI revolution was a step forward or backward?"
Puckette: "I think it was a huge step sideways."
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
31 Aug
31 Aug
12:58 a.m.
New subject: An atrocity committed with PD (MIDI Spec)
On Thu, 2007-08-30 at 11:33 +0200, Nick Copeland wrote:
A vast number of the controllers are already linked up
to fine/coarse,
some of which have definitions regarding functionality, especially for
tuning features. There is also the Non Registered Parameter feature
that extends the number of continuous fine/coarse controllers to
14bits (16K resolution) at the expense of a few extra messages using
the Data Entry CC. The extra messages do not necessarily add much
further latency since few people actually run MIDI over MIDI cables
- MIDI/USB and MIDI/FW are more common these days, the small MIDI
messages running 200Mb/s plus is very little latency.
14 bit MIDI is fundamentally misdesigned for use with a general purpose
operating system. the MMA got the spec backwards: they should transmit
the LSB and then optionally the MSB but instead, they specified
transmission of the MSB first then optional LSB. this makes it extremely
hard to design a proper s/w receiver for 14 bit controller messages.
i've actually discussed this with the technical head at the MMA and he
agreed that it was an oversight mostly born of the fact that the initial
implementations were all "poured in silicon" and had a fixed rate clock
running (generally at the MIDI data rate) which makes it relatively easy
to handle this specification - if the next "tick" does not produce the
MSB, just update the low 7 bits. doing this on linux or other general
purpose O/S's is quite tricky.
--p
30 Aug
30 Aug
9:34 a.m.
On Wed, 29 Aug 2007 22:35:37 -0700
Ken Restivo <ken(a)restivo.org> wrote:
I modified a PD sample-mangling patch, attached MIDI
CC's to some of its parameters, loaded it up with a sample from a classic "Space
Ghost" episode, and spent a few minutes of gleeful insanity tweaking MIDI faders.
Props for using SG in this atrocity!
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
6:58 p.m.
On 8/30/07, Joe Hartley <jh(a)brainiac.com> wrote:
On Wed, 29 Aug 2007 22:35:37 -0700
Ken Restivo <ken(a)restivo.org> wrote:
yeah, nice source material, and i think it's use is consistent with the
spirit of the original...
any chance you'd post the sample-mangling pd patch, or explain how it was
put together?
bernie
I modified a PD sample-mangling patch, attached
MIDI CC's to some of its
parameters, loaded it up with a sample from a classic
"Space Ghost" episode,
and spent a few minutes of gleeful insanity tweaking MIDI faders.
Props for using SG in this atrocity!
1 Sep
1 Sep
7:19 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Aug 30, 2007 at 01:58:28PM -0700, bernie arai wrote:
On 8/30/07, Joe Hartley <jh(a)brainiac.com>
wrote:
It is the 3.audio.examples/B13.sampler.overlap.pd example patch, modified very slightly to
split the outputs to separate dac~ channels, and to add MIDI ctlin objects to control the
parameters.
I played a short solo liveset tonight at a local coffee shop, and originally planned to
try unleashing Space Ghost upon the unsuspecting patrons, but got distracted dealing with
a bunch of unrelated technical difficulties, and chickened out at the last minute.
That patch produces some ear-splitting screeches, which simply aren't everyone's
cup of chai latte. Although, in hindsight, Space Ghost might have been just the right
thing to pull it out of the fire.
By the way, my technical difficulties included my USB controller suddenly deciding to only
pass note messages from one key on the keyboard! The solution was to recall the stored
settings again, but I didn't discover that until after getting home. Also, JACK was
making me crazy by refusing to disconnect graphs, and QJackCtl wasn't showing them,
but they were definitely connected. Also, seq24 transposed a track up an octave, without
my telling it to do so.
I have to make my livesets a lot simpler. Loading up, connecting, and configuring 7
different softsynths plus Ardour (as a mixer) for each song, is just not going to cut it.
For band sets it's not a problem: I have a script that loads up every synth at the
start of the night and then I just use aconnect to switch between synths between/during
songs. For solo sets, it might be time for me to start playing with LASH, and/or just
consolidating and simplifiying stuff.
Also, stuff I write here at home using a studio-like workflow (i.e. centered around
Ardour) might not be the best things to try to jam on live. Perhaps it'd be better to
treat livesets as whole different animal entirely.
- -ken
On Wed, 29 Aug 2007 22:35:37 -0700
Ken Restivo <ken(a)restivo.org> wrote:
yeah, nice source material, and i think it's use is consistent with the
spirit of the original...
any chance you'd post the sample-mangling pd patch, or explain how it was
put together?
I modified a PD sample-mangling patch, attached
MIDI CC's to some of its
parameters, loaded it up with a sample from a classic
"Space Ghost" episode,
and spent a few minutes of gleeful insanity tweaking MIDI faders.
Props for using SG in this atrocity! -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG2S5pe8HF+6xeOIcRAnK+AJ0Y5Q13FomeoA6K6vKIBbgtswQeJgCggOXU
nHDhmll+ayM6iOhrQ3DV9Fw=
=M/6Z
-----END PGP SIGNATURE-----
6245
days inactive
6248
days old
linux-audio-user@lists.linuxaudio.org
12 comments
12 participants
participants (12)
-
Arnold Krille -
bernie arai -
david -
Folderol -
Frank Barknecht -
hard off -
Joe Hartley -
Ken Restivo -
Nick Copeland -
Paul Davis -
Steve McConville -
Thorsten Wilms