 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/14/2011 10:16 AM, Invisible wrote:
>> For me, PD is a novel toy...
>
> As I say, it looks too low-level for me.
It is low-level. But, really, its not supposed to be a high-level tool.
But-- If you're working on a softsynth, or fooling around with DSP
techniques, it beats coding up a program, since it already has the
framework laid down, all you need to do is make the connections. It can
also do things live, which can be interesting.
> I use GNUplot from time to time, and that annoys me with its lame
> interface too. I keep promising myself that some day I'll make a proper
> graphing tool...
Yeah, GNUPlot sucks. My use for Maxima is mostly for simply quickly
plugging something in, and solving it w/o having to manually do the
algebra.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 14 Feb 2011 18:47:09 +0100, Le_Forgeron wrote:
> Le 14/02/2011 18:00, Jim Henderson nous fit lire :
>> On Mon, 14 Feb 2011 16:49:17 +0100, Le_Forgeron wrote:
>>
>>> IIRC, opinions are like a**h*l*s... everybody get one...
>>
>> And they all stink. ;-)
>
> Nah, mine is smelling a fine perfurm of subtile vanilla, rose and lily;
> A real delicacy.
I don't want to know how you determined that. ;-)
> And as usual, our own fart have no odor at all. ;-)
But of course! But in keeping with the original idea of the statement,
one never thinks one's own opinions are wrong - just everyone else's. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2011 18:47, schrieb Le_Forgeron:
> Le 14/02/2011 18:00, Jim Henderson nous fit lire :
>> On Mon, 14 Feb 2011 16:49:17 +0100, Le_Forgeron wrote:
>>
>>> IIRC, opinions are like a**h*l*s... everybody get one...
>>
>> And they all stink. ;-)
>
> Nah, mine is smelling a fine perfurm of subtile vanilla, rose and lily;
> A real delicacy.
>
> And as usual, our own fart have no odor at all. ;-)
... except for the /really/ satisfying ones. They /have/ to :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.02.2011 16:46, schrieb Invisible:
> On 14/02/2011 02:05 PM, Mike Raiford wrote:
>> Ever heard of it? Have an opinion? Just curious. Been kinda poking
>> around it, neat little graphical DSP type thingy. Though looks crude, is
>> quite flexible, a lot you can do with it.
>
> Looks very hackish to me. I probably wouldn't like it.
>
> The (very expensive) Reaktor software I have already does approximately
> this with audio. (But with cleaner abstractions.) And there's WinAmp's
> AVS and Milkdrop plugins that do roughly the same for video.
> (Unfortunately, those are quite hackish as well.)
... and not to forget Matlab/Simulink.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> As I say, it looks too low-level for me.
>
> It is low-level. But, really, its not supposed to be a high-level tool.
Same reason I dislike C. ;-)
> But-- If you're working on a softsynth, or fooling around with DSP
> techniques, it beats coding up a program, since it already has the
> framework laid down, all you need to do is make the connections. It can
> also do things live, which can be interesting.
Same goes for Reaktor. Except that that has a pretty GUI and comes with
a truckload of soft synths that are useful out-of-the-box. (OTOH, it's a
very expensive product...)
>> I use GNUplot from time to time, and that annoys me with its lame
>> interface too. I keep promising myself that some day I'll make a proper
>> graphing tool...
>
> Yeah, GNUPlot sucks. My use for Maxima is mostly for simply quickly
> plugging something in, and solving it w/o having to manually do the
> algebra.
Doesn't Maxima (and every other CAS that isn't Mathematica) use GNUplot
for all its graphing?
Anyway, Wolfram Alpha lets you solve most things for free. If you can
convince it to comprehend the question, and if Wolfram haven't
deliberately disabled it. For that is the biggest problem with WA;
Wolfram talks the big talk about "making everything computable", but if
the full version of Mathematica, would there? Thus, they have
deliberately disabled certain queries.
If only I had the time and the expertise to build something similar
myself... (Ha! Like anybody has that much time and energy.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2/15/2011 3:20 AM, Invisible wrote:
>>> As I say, it looks too low-level for me.
>>
>> It is low-level. But, really, its not supposed to be a high-level tool.
>
> Same reason I dislike C. ;-)
>
And why I so very much love C and C++. I like the whole down to the
metal thing. Granted C# is a nice departure, and can actually be rather
pleasant to work with at times, and it will, if you ask it to allow you
plenty of opportunity to shoot yourself in the foot quite well. You just
have to say "Now, I'd like the opportunity to shoot myself in the foot,
can you look the other way for a moment" ...
then after attempting to shoot yourself in the foot:
"Ok, all done here. You can turn around now. There's good news, and bad
news: The good news is I missed. The bad news is left a big gaping hole
in the floor; I hope you don't fall in."
To which the CLR will reply "Oh, crap. Not again."
>> But-- If you're working on a softsynth, or fooling around with DSP
>> techniques, it beats coding up a program, since it already has the
>> framework laid down, all you need to do is make the connections. It can
>> also do things live, which can be interesting.
>
> Same goes for Reaktor. Except that that has a pretty GUI and comes with
> a truckload of soft synths that are useful out-of-the-box. (OTOH, it's a
> very expensive product...)
>
Does it have a demo? I'd like to play with it. But yeah, PD's UI is
quite ...primitive (That should get understatement of the year)
What I don't like, is there's no good way to visualize how multiple
inputs are being sent to a control port. They're sent in the order of
creation. Which is nice, the user has total control on how messages are
ordered when passed, but is also a bitch when looking at it after you've
created something and wondering why it doesn't seem to be working the
way you need it to.
>
> Doesn't Maxima (and every other CAS that isn't Mathematica) use GNUplot
> for all its graphing?
>
Yes, Maxima does. Hence why I've learned it sucks. Especially on the
Windows platform. That's OK. I have a graphing calculator program that
works quite well for drawing pretty graphs.
> Anyway, Wolfram Alpha lets you solve most things for free. If you can
> convince it to comprehend the question, and if Wolfram haven't
> deliberately disabled it. For that is the biggest problem with WA;
> Wolfram talks the big talk about "making everything computable", but if
> the full version of Mathematica, would there? Thus, they have
> deliberately disabled certain queries.
So does Maxima, and it lives on the computer as a desktop application,
and doesn't need to do a web query and can generally pop results back
quicker. Which allows a bit of fiddling with the inputs. You can also
save the worksheet for later.
> If only I had the time and the expertise to build something similar
> myself... (Ha! Like anybody has that much time and energy.)
Heh.... Yeah, I'm not exactly keen on writing a CAS in my spare time
either.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> It is low-level. But, really, its not supposed to be a high-level tool.
>>
>> Same reason I dislike C. ;-)
>>
>
> And why I so very much love C and C++. I like the whole down to the
> metal thing.
No, see, that's why I like writing in *assembly*. But C pretends to be
high-level, but isn't.
Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
In C, I say... um, well it seems to vary by compiler/OS. WTF? And this
is supposedly a language *designed* for low-level programming? Yeah, right.
Assembly gives you total control, if that's what you want. Haskell lets
you get on with writing a complex algorithm, if that's what you want. C
lets you do neither of these things.
>> Same goes for Reaktor. Except that that has a pretty GUI and comes with
>> a truckload of soft synths that are useful out-of-the-box. (OTOH, it's a
>> very expensive product...)
>>
>
> Does it have a demo? I'd like to play with it. But yeah, PD's UI is
> quite ...primitive (That should get understatement of the year)
Yes - but it's temporarily unavailable. (How typical!)
The product page is at
http://www.native-instruments.com/#/en/products/producer/reaktor-5/
From there you can look at screenshots, listen to some of the demo
tunes, and if you click "downloads" you can download the complete User
Manual, which will tell you something about what the product can and
can't do.
Normally the downloads page would also have a "request a demo" button,
which sends you an email with a unique URL to a download. The program
runs for 30 days with saving disabled, but otherwise it's fully
functional. (If you type in a registration key, it becomes the full
product.)
I presume you've also heard by rendition of Silhouettes? That was made
using nothing but one single synth that comes with the default Reaktor
install. (A synth called Steam Pipe.) It uses waveguide synthesis to
make quite authentic wind and string sounds. In case you wanted to know
what Reaktor sounds like in the hands of a typical person, not the NI
marketing department. ;-)
> What I don't like, is there's no good way to visualize how multiple
> inputs are being sent to a control port. They're sent in the order of
> creation. Which is nice, the user has total control on how messages are
> ordered when passed, but is also a bitch when looking at it after you've
> created something and wondering why it doesn't seem to be working the
> way you need it to.
Reaktor has a few annoying limitations too.
- You can create "components", but changing one instance of a component
doesn't affect any of the other instances.
- There are no looping constructs.
The first one doesn't bite too much if you implement your components
correctly first time. If you don't, it's a PITA.
The second one means that if, say, you wanted a bank of 200 filters each
tuned to a different frequency... you have to insert all 200 filters by
hand, one at a time.
[There's a hack: Create a synth with 200 notes polyphonic, put one
filter into it, and use the voiceID to set the filter's frequency.
Needless to say, this trick only works once per synth...]
>> Doesn't Maxima (and every other CAS that isn't Mathematica) use GNUplot
>> for all its graphing?
>
> Yes, Maxima does. Hence why I've learned it sucks.
LOL!
> Especially on the Windows platform.
*Everything* with GNU in the name sucks on Windows!
>> Anyway, Wolfram Alpha lets you solve most things for free.
>
> So does Maxima, and it lives on the computer as a desktop application,
> and doesn't need to do a web query and can generally pop results back
> quicker. Which allows a bit of fiddling with the inputs. You can also
> save the worksheet for later.
Wolfram knows things like unit conversion factors, and it knows formulas
that you'd have to look up in a textbook if you wanted Maxima to compute
them. Plus you can use it to look up statistics that Maxima doesn't have
access to.
On the other hand, it can only answer questions simple enough to be
written as a single question. Maxima (or any other desktop application)
has the killer advantage that you can build far more complex scenarios
with it.
>> If only I had the time and the expertise to build something similar
>> myself... (Ha! Like anybody has that much time and energy.)
>
> Heh.... Yeah, I'm not exactly keen on writing a CAS in my spare time
> either.
At its core, Mathematica is a transformation engine. The engine knows
nothing about mathematics; it just takes an expression and applies any
applicable transformation rules to it, repeatedly until no more rules
apply. You can (and people have) use it for things that aren't math.
Implementing Mathematica's transformation engine is a relatively
straight-forward task. Duplicating Mathematica's extensive library of
mathematical transformations is not. (!) They've put 20+ years of R&D
into that library. There's no way one person is going to duplicate it in
ten minutes.
(It's a bit like saying that writing an OS kernel is easy, but building
a complete desktop OS is not.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
> In C, I say...
uint64_t
(Yes, it has been standard for almost 12 years already.)
> Assembly gives you total control, if that's what you want.
And how do you specify a 64-bit unsigned integer in assembly, exactly?
(Remember: You complained how C integral types are system-dependent.)
> Haskell lets
> you get on with writing a complex algorithm, if that's what you want. C
> lets you do neither of these things.
Depends on the algorithm. (C++ is definitely better in this aspect
because in many cases it removes the need to worry about memory management
so you can just concentrate on the algorithm itself, although not always.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Like, in Haskell, if I want a 64-bit unsigned integer, I say "Word64".
>> In C, I say...
>
> uint64_t
>
> (Yes, it has been standard for almost 12 years already.)
Well, now I've seen everything... (All the sources I looked at said you
have to write "long long unsigned int" or some mojo like that.)
>> Assembly gives you total control, if that's what you want.
>
> And how do you specify a 64-bit unsigned integer in assembly, exactly?
> (Remember: You complained how C integral types are system-dependent.)
In assembly, you don't even "specify" how big a given data item is. This
is an implicit property of what instructions you use on that data.
Assembly isn't even high-level enough to pretend that it has data types.
It just supports what the hardware supports.
There's a reason most people don't write assembly any more.
>> Haskell lets
>> you get on with writing a complex algorithm, if that's what you want. C
>> lets you do neither of these things.
>
> Depends on the algorithm.
I would imagine so.
> C++ is definitely better in this aspect
Agreed. Writing programs that work properly seems a lot easier in C++
than in C.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> Assembly gives you total control, if that's what you want.
> >
> > And how do you specify a 64-bit unsigned integer in assembly, exactly?
> > (Remember: You complained how C integral types are system-dependent.)
> In assembly, you don't even "specify" how big a given data item is. This
> is an implicit property of what instructions you use on that data.
> Assembly isn't even high-level enough to pretend that it has data types.
> It just supports what the hardware supports.
Hence you are contradicting yourself. You *don't* have "total control"
if you can't even specify the size of your integrals.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
