28 Apr
2008
28 Apr
'08
9:39 p.m.
Greetings,
Has anyone here successfully loaded the "factory preset" patches for
Malte Steiner's Minicomputer synthesizer ? I use the Import Sounds
button, it appears to load the minicomputerMemory.txt set but none of
the individual patches appear in the patch list (the entry box labeled
"sound").
I've failed with 1.0 and 1.1. Any suggestions ?
Best,
dp
28 Apr
28 Apr
10:02 p.m.
Dave Phillips wrote:
Greetings,
Has anyone here successfully loaded the "factory preset" patches for
Malte Steiner's Minicomputer synthesizer ? I use the Import Sounds
button, it appears to load the minicomputerMemory.txt set but none of
the individual patches appear in the patch list (the entry box labeled
"sound").
I've failed with 1.0 and 1.1. Any suggestions ?
Never mind.
$HOME/.minicomputer/minicomputerMemory.txt does the trick.
Now is there some reason it's not responding to MIDI controllers or
note-ons ? Program changes are received fine.
This is 1.0, btw.
Best,
dp
10:10 p.m.
Dave Phillips wrote:
... is there some reason it's not responding to
MIDI controllers or note-ons ? Program changes are received fine.
Never mind again.
It's responding to MIDI note-ons, but if it's
responding to controllers the affected parameters are showing no visible
changes.
I'm just happily carrying on by myself here... ;)
Best,
dp
29 Apr
29 Apr
8:14 a.m.
Hello,
I wrote Minicomputer and indeed you have to copy that file to your
.minicomputer file, something which soon will be done by a
installer/deinstaller I intend to provide. The ex/import is only for
single sounds which I thought it would be handy for exchange sounds.
The gui and the soundengine are two programs, Midi note controlling has
to be connected to minicomputer while the editor only takes prg changes,
which I wrote in the manual, I hope :).
Cheers,
Malte
--
-------------
Malte Steiner
http://www.block4.com
media art + development
8:23 a.m.
Malte Steiner wrote:
I wrote Minicomputer and indeed you have to copy that
file to your
.minicomputer file, something which soon will be done by a
installer/deinstaller I intend to provide. The ex/import is only for
single sounds which I thought it would be handy for exchange sounds.
The gui and the soundengine are two programs, Midi note controlling has
to be connected to minicomputer while the editor only takes prg changes,
which I wrote in the manual, I hope :).
Hi Malte,
I don't know whether you got my message I sent to you last night, but I
think I have most of it figured out now. Thanks for the further
clarification. I understood the "two programs" aspect, no problems there.
Minicomputer is a very fine synth, thank you for creating it and giving
it to the libre software world. It is most appreciated.
Best,
dp
8:16 a.m.
Dave Phillips wrote:
Never mind again. It's responding to MIDI
note-ons, but if it's
responding to controllers the affected parameters are showing no visible
changes.
Last night I figured out how this synth handles audio and MIDI I/O.
It's
a bit oddly designed, but I must say that some of its sounds are
amazing. It's not terribly difficult to program, it's essentially a
souped-up subtractive synthesis architecture, and since its patches are
saved as simple text files it's also fairly easy to copy & paste sounds
to more easily create what the synth calls a Multi.
Apparently the graphics do not respond to incoming messages in realtime,
but the sounds do. The modulation capabilities in Minicomputer are quite
effective, I had a lot fun last night using MIDI note-on and velocity
values to liven up some sounds.
IMO, a very cool synth. A little difficult to comprehend at first, but
well worth the effort.
Best,
dp
9 a.m.
Thanks for the kudos. Actually I checked first the LAU mails than my
personal ones, thats why I responded first here.
Have you seen the comprehensive manual for Minicomputer I wrote? I would
like to know your opinion about it, I actually hold back the release
until I finished it.
About the two program design, maybe I fiddled to much with the way DSSIs
work (and decided then to write a standalone anyway :) ) but I thought
it would be the appropriate aproach to write such a synth for Linux but
I might be wrong. Feedback from the community and advices would be
highly appreciated because I have more ideas in mind for strange sounds.
But first we have to make a new Alsa Modular release because there are
some exciting changes in the pipeline and even in the CVS. And a new
release for Minicomputer is due too because I have the feeling that Midi
processing takes to much cpu cycles on the latest 1.1 release...
Cheers,
Malte
--
-------------
Malte Steiner
http://www.block4.com
media art + development
9:18 a.m.
Even tho the approach is not 'out there' (as it seems quite a bit of
linux programs use this client / server approach) I have the feeling
it's the kind of details that could pull off users from adopting linux
as a music platform. If you plan on trying a synth, you'd want to see
it's face right ? It's kind of the same as the jackd/jackstart/qjackctl
issue. When I tryed it first, I got really confused by all of them.
Actually, I still didn't get the jackstart/jackd difference, my eee
seems to need jackstart, my ubuntu install doesn't even have one.
In my views, a single executable would be a lot better, and if anybody
wants to run it without a GUI, give them a command-line option. Sure
that will mean your main executable will depend on user interface libs
but i don't see anybody wanting to run the synth without wanting to
tweak it at some point so the libs will be needed anyway....
my 2 cents :)
Marc.
Malte Steiner a écrit :
Feedback from the community and advices would be
highly appreciated because I have more ideas in mind for strange sounds.
10:01 a.m.
M-.-n wrote:
Even tho the approach is not 'out there' (as
it seems quite a bit of
linux programs use this client / server approach) I have the feeling
it's the kind of details that could pull off users from adopting linux
as a music platform. If you plan on trying a synth, you'd want to see
it's face right ? It's kind of the same as the jackd/jackstart/qjackctl
issue. When I tryed it first, I got really confused by all of them.
Actually, I still didn't get the jackstart/jackd difference, my eee
seems to need jackstart, my ubuntu install doesn't even have one.
In my views, a single executable would be a lot better, and if anybody
wants to run it without a GUI, give them a command-line option. Sure
that will mean your main executable will depend on user interface libs
but i don't see anybody wanting to run the synth without wanting to
tweak it at some point so the libs will be needed anyway....
Respectfully, I
disagree. The client/server architecture is one I wish
more synths would adopt. Thanks to this design, the engine may be
controlled by MIDI or OSC, can be run with or without a (possibly
custom) GUI, and allows the engine to be used for purposes other than
those originally intended. The client/server distinction confers great
flexibility, though it may not be immediately apparent to the new user.
Linuxsampler works this way, as does SuperCollider3, and I believe the
new Csound API permits similar operation.
Best,
dp
10:27 a.m.
Dave Phillips a écrit :
Respectfully, I disagree. The client/server
architecture is one I wish
more synths would adopt. Thanks to this design, the engine may be
controlled by MIDI or OSC, can be run with or without a (possibly
custom) GUI, and allows the engine to be used for purposes other than
those originally intended. The client/server distinction confers great
flexibility, though it may not be immediately apparent to the new user.
Hey Dave,
I understand your point. I was not saying the client/server 'awareness'
had to be ditched. Even as a monolotic exe, OSC, midi, and any other
protocol could still exist.
My point was that when I decide to do music I don't have hours to kill
and reading man pages/collecting contradictory information on the web is
the last thing I feel like doing... In my eye, "ease of use" should
never be sacrificed against flexibility. In malte's case it could be
just a shell script that fires both exes.
In my view, It's up to the developpers to sort out the issues of
'getting started' and make his/her work usable... and it's all to his
benefits, otherwise his work is going to be restricted to a few
die-hards and all the time and love spend coding stuff is going to be
'wasted'...
Linux is a great platform but it has miles to cover before it can
'compete' with the mainstream players in term of audio. And I'm not
talking about capacities, inventivity or available software but only due
to the fact setup is a bitch: I consider myself not being a retard and I
haven't been able to get a rt kernel working properly on any of my machines.
Usability out of the box is the biggest challenge. Everyone working on
any piece of the puzzle should focus on it.
I guess I'm going to get fragged for saying that :)
++
Marc.
11:52 a.m.
M-.-n wrote:
My point was that when I decide to do music I
don't have hours to kill
and reading man pages/collecting contradictory information on the web
is the last thing I feel like doing... In my eye, "ease of use" should
never be sacrificed against flexibility. In malte's case it could be
just a shell script that fires both exes.
Hi Marc,
I understand your point, but I'll take power over ease any day.
Nevertheless, I agree with you re: the new user. If new users are going
to get into this stuff they need a lot of hand-holding, and this is true
regardless of platform. It is a matter of design.
In my view, It's up to the developpers to sort out
the issues of
'getting started' and make his/her work usable... and it's all to his
benefits, otherwise his work is going to be restricted to a few
die-hards and all the time and love spend coding stuff is going to be
'wasted'...
This argument assumes that "more is better". In my
personal world,
"better is better".
Again, I still agree with your basic contention. Software should never
ignore the user's potential for confusion, especially when the software
in question is complex by nature. Ah, but how to balance access and
power, that is the question. Classic Csound resolves the issue by
tossing it out the window, i.e. you are required to learn its language
or you will be limited by the design limitations of whatever front-end
you prefer (though some are certainly better than others). I don't
disagree with that tack, but it's difficult to attract new users without
giving them polished and shiny GUIs. That's not a complaint, it's just
"where we at" in the general sound & music software world.
Linux is a great platform but it has miles to cover
before it can
'compete' with the mainstream players in term of audio. And I'm not
talking about capacities, inventivity or available software but only
due to the fact setup is a bitch: I consider myself not being a retard
and I haven't been able to get a rt kernel working properly on any of
my machines.
You're not using one of the optimized distros ? If not, you've
set
yourself up for (IMHO) needless mucking about with kernel compilation
and other unnecessary activity. I've been at this Linux audio game for
long enough, and I don't care if I never compile another kernel.
Happily, the maintainers of 64 Studio, JAD, Planet CCRMA, MusiX, and
everyone else listed at http://linux-sound.org/distro.html have made
that involvement a dim memory for me.
In other words, if you want a better out-of-the-box Linux audio
experience then you should open a more appropriate box.
Btw, please don't take this commentary as a personal jab. I truly
believe that more problems come from new (and not so new) users naively
believing that *any* Linux distro is good enough for pro-quality audio
performance, if they just toss in the right kernel, and set those
priorities, and find the necessary drivers and firmware, and tweak those
JACK and ALSA settings... Gahh, what a pile of work, and it usually
results in the conclusion that Linux just isn't up to the task. The
conclusion is wrong because the starting premise (i.e. the distro) was
wrong.
Setup for my last two installs (JAD and 64 Studio) was anything but a
bitch. Yes, I still had to tweak a few things, because I have a rather
complicated setup here, but I have an advantage in knowing exactly what
I'm doing (or who to ask ;).
Of course, if you *are* using an optimized distro then you're having
problems that need to be communicated to the maintainers.
Usability out of the box is the biggest challenge.
Everyone working on
any piece of the puzzle should focus on it.
I guess I'm going to get fragged for saying that :)
Not at all. Your points are
generally valid, regardless of what distro
you've used. Typical software shouldn't present hurdles for the new
user, though I will add that more specialized software may require more
specialized knowledge before its capabilities can be more fully appreciated.
Thanks for sharing your POV, Marc. Please continue to do so. :)
Best,
dp
12:15 p.m.
Dave Phillips a écrit :
Again, I still agree with your basic contention.
Software should never
ignore the user's potential for confusion, especially when the software
in question is complex by nature. Ah, but how to balance access and
power, that is the question. Classic Csound resolves the issue by
tossing it out the window, i.e. you are required to learn its language
or you will be limited by the design limitations of whatever front-end
you prefer (though some are certainly better than others). I don't
disagree with that tack, but it's difficult to attract new users without
giving them polished and shiny GUIs. That's not a complaint, it's just
"where we at" in the general sound & music software world.
Indeed, it's all a question of time. Unfortunately, we can't spend all
the time we want on 'discovering' and this will always somehow lead our path. When
I first found about Csound (man that was years ago) I was baffled because it was all I
ever dreamed of. However, in the long run, I realised its 'interface' made
everything a long crawl. Although it's a mighty program to do experiments, I realised
I could do more interesting stuff with, let's say, a Nord Modular, than Csound. Not
because of the power but because of the hit/miss ratio and the time a whole cycle of test
would take. I haven't tried it since the day of the Csound book tho (I wrote a chapter
in it :) and it is possible it is a lot more friendly now. (I know the nord mod isn't
based on an os, but I find it to be an interesting case.. it's just software after
all)
In other words, if you want a better out-of-the-box
Linux audio
experience then you should open a more appropriate box.
Thanks for pointing that out. I will indeed try. My vaio should, I
guess, be no problem (finger crossed) but how many chance would I get to
run that on a EEE in your opinion ?
Btw, please don't take this commentary as a
personal jab. I truly
believe that more problems come from new (and not so new) users naively
believing that *any* Linux distro is good enough for pro-quality audio
performance, if they just toss in the right kernel, and set those
priorities, and find the necessary drivers and firmware, and tweak those
JACK and ALSA settings... Gahh, what a pile of work, and it usually
results in the conclusion that Linux just isn't up to the task. The
conclusion is wrong because the starting premise (i.e. the distro) was
wrong.
I'm not taking it personally at all, and see, with the discussion, I
learned something. But I wonder why most people (not here but other
sources I chatted with) told me to fiddle with kernel recompilation &
pam security rather than pointing me to a special distro. It's kind of
interesting...
Thanks for sharing your POV, Marc. Please continue to
do so. :)
I will, no problem !
Regards,
Marc.
30 Apr
30 Apr
12:53 p.m.
Dave Phillips wrote:
I truly
believe that more problems come from new (and not so new) users naively
believing that *any* Linux distro is good enough for pro-quality audio
performance, if they just toss in the right kernel, and set those
priorities, and find the necessary drivers and firmware, and tweak those
JACK and ALSA settings...
Ok, I run Ubuntu (recently switched from debian) and although ubuntu is
performing well and debian very well, I'm interrested in trying out a
dedicated pro-audio distro. I tried agnula once and was very
disappointed, but maybe things improved...
Looking at the list, trying to remember which name I heard the most
times, and trying to stick with something debian-based I guess I should
try out 64 studio, right?
Could you fill in these datails that I wasn't able to (quickly) loacate
on the web site:
1) What's the relation with debian? Is it based on testing or stable? Or
is it totally self contained?
2) What's the release rate?
3) Am I gonna break the whole thing when using it as a "regular" linux,
with everything that includes (wlan, 3d-accel/compiz, bluetooth,
suspend/hibernate, cups, dual monitors, all those non-pro-audio things
that tend to work well in ubuntu and seems to conflict with rock-steady
audio performance).
--
peace, love & harmony
Atte
http://atte.dk | http://myspace.com/attejensen
http://anagrammer.dk | http://modlys.dk
1:09 p.m.
Atte André Jensen wrote:
Could you fill in these datails that I wasn't able
to (quickly) loacate
on the web site:
1) What's the relation with debian? Is it based on testing or stable? Or
is it totally self contained?
It is a strict 64-bit Debian distribution, currently running with an
Etch core, IIRC.
There is also a "legacy" 32-bit version.
2) What's the release rate?
Slow, like Debian itself, but I compile lots of things myself anyway.
3) Am I gonna break the whole thing when using it as a
"regular" linux,
with everything that includes (wlan, 3d-accel/compiz, bluetooth,
suspend/hibernate, cups, dual monitors, all those non-pro-audio things
that tend to work well in ubuntu and seems to conflict with rock-steady
audio performance).
I use it for my writing, for my business needs, for listening
to music,
for watching videos, for making music with a large variety of Linux
audio software, etc.
The system here is using the proprietary nVidia driver for my 7600GS
video card. It's been working nicely for quite a while now. In fact, 64
Studio is the most rock-steady system I've tried since Planet CCRMA's
Red Hat days. I can't recall the last time it locked up or crashed.
You can try a live version to see how it treats your hardware.
Did I mention that it's fast ? :)
Best,
dp
1:21 p.m.
Dave Phillips wrote:
In fact, 64
Studio is the most rock-steady system I've tried since Planet CCRMA's
Red Hat days. I can't recall the last time it locked up or crashed.
Ditto.
--
Orpheus Media Research, LLC
http://www.orpheusmediaresearch.com/
8:04 p.m.
Dave Phillips wrote:
Did I mention that it's fast ? :)
I ran the live cd, and it beats the sh** out of my debian or ubuntu
setup. 2ms latency without x-runs.
However I'm having trouble installing, since I don't have a dvd-burner.
I tried installing from usb-stick following this guide
(http://64studio.com/node/262) but the installer fails complaining about
missing kernel modules.
This is the content of my stick:
atte@ajstrup:~$ ll /media/disk/
total 778M
-rwx------ 1 atte root 773M 2008-04-30 21:54 64studio_2.0_i386.iso
-rwx------ 1 atte root 4,1M 2008-04-30 21:52 initrd.gz
-r-x------ 1 atte root 13K 2008-04-30 21:51 ldlinux.sys
-rwx------ 1 atte root 51 2008-04-30 22:09 syslinux.cfg
-rwx------ 1 atte root 1,2M 2008-04-30 21:52 vmlinuz
atte@ajstrup:~$ cat /media/disk/syslinux.cfg
default vmlinuz
append initrd=initrd.gz ramdisk_size=10240 root=/dev/rd/0
devfs=mount,dall rw
Anyone did this (install 64 studio from usb-stick) or is able to spot my
mistake?
--
peace, love & harmony
Atte
http://atte.dk | http://myspace.com/attejensen
http://anagrammer.dk | http://modlys.dk
29 Apr
29 Apr
2:02 p.m.
I plan to implement an automated start and stop of the synthcore through
the editor so it going to be transparent for the user that Minicomputer
is actually made of two programs. While I think it addresses only a
fraction of users (dont expect a piano from it) it should be made as
accessible as possible. But shiny GUIs, I don't know. The look stays the
way it is. It stirred up some discussion but the look is a statement of
Minicomputer, Industrial.
Maybe in future synths (certainly not in the next one which is a
derivate of Minicomputer and work with wavetables, not in Creative Labs
but in PPG sense :) ) I will unify the application and handle the GUI in
a separate thread for technical reasons so it integrates better or more
easily for me as a programmer. But an remote access through something
like OSC should come with it.
But yeah, I am using Nord Modular and Csound regularly even today, so
its the right tool for the right purpose :)
Cheers,
Malte
--
-------------
Malte Steiner
http://www.block4.com
media art + development
3:06 p.m.
Malte Steiner wrote:
I plan to implement an automated start and stop of the
synthcore through
the editor so it going to be transparent for the user that Minicomputer
is actually made of two programs. While I think it addresses only a
fraction of users (dont expect a piano from it) it should be made as
accessible as possible. But shiny GUIs, I don't know. The look stays the
way it is. It stirred up some discussion but the look is a statement of
Minicomputer, Industrial.
Great statement! :-)
Maybe in future synths (certainly not in the next one
which is a
derivate of Minicomputer and work with wavetables, not in Creative Labs
but in PPG sense :) )
I am really looking forward to this. Two feature requests:
1) The ability to modulate between two or more wavetables.
2) Whole patch randomizer.
I will unify the application and handle the GUI in
a separate thread for technical reasons so it integrates better or more
easily for me as a programmer. But an remote access through something
like OSC should come with it.
But yeah, I am using Nord Modular and Csound regularly even today, so
its the right tool for the right purpose :)
Couldn't agree more. There are some things that can only be accomplished
with audio programming languages (both visual and text-based, the latter
will always be more versatile and expressive IMO, but maybe less
inspiring). And it 's also true that sometimes you just want to pick up
a synth and tweak the knobs for instant gratification/inspiration.
All the best,
-c.
Cheers,
Malte
3:14 p.m.
Great thing. Make also sure there's a default sound set loaded when first
starting it and it'll be awesome :)
I plan to implement an automated start and stop of the
synthcore through
the editor so it going to be transparent for the user that Minicomputer
is actually made of two programs.
6052
days inactive
6054
days old
linux-audio-user@lists.linuxaudio.org
19 comments
6 participants
participants (6)
-
Atte André Jensen -
Cesare Marilungo -
Dave Phillips -
Dr. Greg Wilder -
M-.-n -
Malte Steiner