electro-music.com   Dedicated to experimental electro-acoustic
and electronic music
 
    Front Page  |  Radio
 |  Media  |  Forum  |  Wiki  |  Links
Forum with support of Syndicator RSS
 FAQFAQ   CalendarCalendar   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   LinksLinks
 RegisterRegister   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in  Chat RoomChat Room 
 Forum index » Clavia Nord Modular » Wish List
More Economic Way Of Using Zero Page Memory
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 2 [29 Posts]
View unread posts
View new posts in the last week
Mark the topic unread :: View previous topic :: View next topic
Goto page: 1, 2 Next
Author Message
LLR3



Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland

PostPosted: Sat Mar 26, 2005 4:20 pm    Post subject: More Economic Way Of Using Zero Page Memory Reply with quote  Mark this post and the followings unread

This is naturally just speculation as I don´t really have any idea how the G2 firmware really works...

Module count on a G2 patch is limited because of the limited amount of zero page memory available on the DSP - wasn´t this what we were told? Would I be badly mistaken if I went on to say that the OUTPUTS on the modules consume one zero page (24-bit) word each?

The Question

Could perhaps some (most?) of the zero page locations be re-used during the execution of the generated code? I mean I can understand that the outputs connected to MORE THAN ONE inputs need a zero page location for temporarily storing the data BUT WHAT ABOUT OUTPUTS THAT ARE ONLY CONNECTED TO ONE INPUT (OR EVEN WORSE: TO NONE AT ALL!)? If the modules are calculated in consecutive order then why do the calculation results need to be available in the zero page area ALL the time?

*LLR3
Back to top
View user's profile Send private message
Afro88



Joined: Jun 20, 2004
Posts: 701
Location: Brisbane, Australia
Audio files: 12
G2 patch files: 79

PostPosted: Sat Mar 26, 2005 5:31 pm    Post subject: Reply with quote  Mark this post and the followings unread

As far as I know, this is how it works. You add a module, the G2 allocates the minimum resources for it. Then as you connect it to other modules, it recalculates the patch and allocates the required resources.

There's no way to tell how it's using "zero page memory".... did you reach the module count limit? I didn't think there was one Shocked
Back to top
View user's profile Send private message Visit poster's website
LLR3



Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland

PostPosted: Sat Mar 26, 2005 6:57 pm    Post subject: Reply with quote  Mark this post and the followings unread

Try placing an 8-to-1 switch on an empty patch, check the memory usage, replace the module with a 1-to-8 switch and compare the results in memory consumption. (In this case the memory usage meter is displaying the percentage of zero page memory used as no modules using external memory are present [right, Clavia?]. BTW, there should definitely be two separate memory usage meters for zero page and external memory!)

The maximum number of modules per patch limit is easily reached when trying to do something more complex on a G2 (or G1). One would of course be very silly to try creating COMPUTER-LIKE ALGORITHMS ON AN ANALOG COMPONENTS SIMULATOR, but what can you do - there´s no better way of doing more advanced things on this BRILLIANT CLAVIA HARDWARE! Well at least not until I reveal my plans for the PROGRAMMABLE CONTROL MODULE for G2 firmware and Clavia implements it!!! Razz

*LLR3
Back to top
View user's profile Send private message
Rob



Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109

PostPosted: Sun Mar 27, 2005 6:18 am    Post subject: Reply with quote  Mark this post and the followings unread

For each output is always a memory location needed to transfer the module output value to the next 96kHz samplerate calculation round. These memory locations are allocated when a module is placed. On the old NM this was hardly an issue as there were hardly any modules with more than one output. But on the G2 it is an issue, e.g. imho the most nasty ones are the keyboard and device modules that eat a lot of memory, while many times one needs only one or two of the signals from these modules. Very nasty when a polysynth patch is just at 31% memory and one only needs the velocity. Then one looses three voices or one has to use the velocity morph (this last one is definitely recommended over using the keyboard module). In some cases I use an Env module in Retrig mode and use its blue output to get the keyboard gate signal.

I've heard that this zero page issue is a known issue at Clavia. Changing the OS to get a more optimal zero page use seems to involve changes very deep in the code. My personal guess is that parts of this very deep level code is ported from the old NM. Anyway, such a change probably involves a major rewrite of lots of the deep level code and all the code that depends in this code. Which would be something like a OS2.x kind of upgrade. Definitely not to be expected soon, I guess.

Btw, there is nothing silly about trying to create computer-like algorithms on the G2, the G2 is very much like a 'virtual analog computer'. A stored program with sequential execution can be effectively made by patching each 'function' with some modules, separate them by S&H modules in a 'bucket brigade' fashion and clocking them with just any osc. This would actually be a nice example of user-defined super-pipelining. And in essence super-pipelining is of course exactly what the G2 already does. Basically one should see the zero page memory locations used by the module outputs as the buckets that are passed from function to function. The great thing about the G2 is that 'buckets' can race through a lot of modules in the right route in just one system sample. Which in practice means that in most cases one doesn't have to separate functions with S&H modules but one can just patch away happily. And get the expected results, due to how the G2 defines the optimal calculation order (= how the buckets race through the patch).

I think that if Alan Turing was still alive he would have loved the G2. Imho the G2 is sort of a musical Turing machine. People like Jan Punter have proven with their noodles that the G2 can 'think for itself' (in the Turing kind of view on thinking). There is noodles that Jan et al has forced the G2 to some 'deep thoughts'. Well, G2 noodles are the closest thing to AI that I've ever seen/heard. Wink
Back to top
View user's profile Send private message Send e-mail Visit poster's website
LLR3



Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland

PostPosted: Sun Mar 27, 2005 10:53 am    Post subject: Reply with quote  Mark this post and the followings unread

Rob wrote:
For each output is always a memory location needed to transfer the module output value to the next 96kHz samplerate calculation round. These memory locations are allocated when a module is placed.


But if the modules are calculated in consecutive order then the calculation results wouldn´t really have to be stored in static zero page locations but instead the zp locations could be re-used when the next module in chain is being processed. (That is IF the output signals are not split into several inputs...) On a G1 (and also on first G2 firmware revisions?) the case was different as the modules clearly weren´t calculated in order.

I bet the zero page usage could (and hopefully will) be further optimized now that the calculation order of the modules has been (at least to some extent?) sorted out.

Rob wrote:
On the old NM this was hardly an issue as there were hardly any modules with more than one output.


Yeah right... I always ran out of available modules on G1 because of the zero page issue. Available CYCLES never were a problem for me - I always run out of zero page memory in my designs.

Rob wrote:
But on the G2 it is an issue, e.g. imho the most nasty ones are the keyboard and device modules that eat a lot of memory, while many times one needs only one or two of the signals from these modules. Very nasty when a polysynth patch is just at 31% memory and one only needs the velocity. Then one looses three voices or one has to use the velocity morph (this last one is definitely recommended over using the keyboard module). In some cases I use an Env module in Retrig mode and use its blue output to get the keyboard gate signal.


Well, I hope Clavia would AT LEAST try optimizing out the need for zp locations for UNUSED outputs. That would be a start...

Rob wrote:
I've heard that this zero page issue is a known issue at Clavia. Changing the OS to get a more optimal zero page use seems to involve changes very deep in the code. My personal guess is that parts of this very deep level code is ported from the old NM. Anyway, such a change probably involves a major rewrite of lots of the deep level code and all the code that depends in this code. Which would be something like a OS2.x kind of upgrade. Definitely not to be expected soon, I guess.


(A million thoughts bouncing in my head...)

I wish there was something that I could do to help... Too bad the development of the G2 is not an open community project... Is there some hardware-wise comparable and affordable, well documented and user programmable equipment available? (I must have asked this before or was it in a dream!? Argh, maybe this all is a nightmare! Starting from scratch on a blank hardware platform!?... in a dark forest - WITH AN OWL!)

This is very OT, but what do you people think: Would it be possible for us to take all the good bits from the NM design and create the ultimate synthesizer as a community project? Actually what I´m really trying ask here is that IF Clavia decided to open their proprietary hardware and software to the community, would we (of course with the help from Clavia) be up to the task to create the ultimate synthesizer from there? And if you think that perhaps WE would be to the task, then could you consider using a different hardware platform in case Clavia wouldn´t agree to co-operate?

...

OK, I admit I went a little bit off-rail but let´s continue with the actual topic...

Rob wrote:
Btw, there is nothing silly about trying to create computer-like algorithms on the G2...


I VERY STRONGLY DISAGREE. As educationally valuable it may be, it´s very far from being practical. I personally feel that I´ve wasted a huge chunk of my youth trying realize various VERY SIMPLE ideas on a G1 platform and ending up with unsatisfactory results. Now that I´ve made it to the G2 platform I try to be wiser and avoid being tempted to try anything that isn´t "readily available". Of course there are many things that CAN be done on a G2 or G1, but I think the PLATFORM IS UNSUITABLE FOR IDEA BASED work. When writing a program in let´s say C language, first you come up with an[y] idea, then perhaps plan the structures and then DO THE CODING. On a NM one can´t really count on being able to realize even the simplest ideas. (OK, you can if your idea of an idea is to route an oscillator through a filter...)

Rob wrote:
...the G2 is very much like a 'virtual analog computer'. A stored program with sequential execution can be effectively made by patching each 'function' with some modules, separate them by S&H modules in a 'bucket brigade' fashion and clocking them with just any osc. This would actually be a nice example of user-defined super-pipelining. And in essence super-pipelining is of course exactly what the G2 already does. Basically one should see the zero page memory locations used by the module outputs as the buckets that are passed from function to function. The great thing about the G2 is that 'buckets' can race through a lot of modules in the right route in just one system sample. Which in practice means that in most cases one doesn't have to separate functions with S&H modules but one can just patch away happily. And get the expected results, due to how the G2 defines the optimal calculation order (= how the buckets race through the patch).


Well, if the NM has ever given me anything (besides tons of totally awesome sounds!) then that must the appreciation for all the engineers creating digital logic out of analog components. (But then again: they at least have REAL analog components as we have to cope with computers PRETENDING to be analogue components...)

Rob wrote:
I think that if Alan Turing was still alive he would have loved the G2. Imho the G2 is sort of a musical Turing machine. People like Jan Punter have proven with their noodles that the G2 can 'think for itself' (in the Turing kind of view on thinking). There is noodles that Jan et al has forced the G2 to some 'deep thoughts'. Well, G2 noodles are the closest thing to AI that I've ever seen/heard. Wink


There´s nothing wrong in diggin´ the thing (NM) for it IS - I just just wish that I had the TOOLS I NEED, but unfortunately I don´t. I wish the Kyma/Capybara platform was very cheap and available for purchase from anywhere, but that isn´t so. (Is there even a software only demo of Kyma available anywhere? Even with no sound? I´d like to try it out...) Maybe the new Cell processor will change everything and we never need to suffer from CPU latency problems ever again...

Uh, I should really be working on a soundtrack that I need to finish for tomorrow. I guess yet another sample collage piece coming up. I wish someday I´ll have the tools to re-invent music - I already have the ideas...

*LLR3
Back to top
View user's profile Send private message
Rob



Joined: Mar 29, 2004
Posts: 580
Location: The Hague/Netherlands/EC
G2 patch files: 109

PostPosted: Sun Mar 27, 2005 11:25 am    Post subject: Reply with quote  Mark this post and the followings unread

LLR3 wrote:
<snip> I just just wish that I had the TOOLS I NEED, but unfortunately I don´t.
<snip>
*LLR3


It occurs to me that the fact that there are tools you need, butyou don't have, can hardly be blamed on the tools that you actually do have.

Perhaps you're just simply ahead of evolution. Wink

Still, you can get a Motorola DSP development kit, or one from some other manufacturer, and program away anyway you wanna go. A couple of hundred euro will put you in business. You will have total freedom to design everything just anyway you can imagine, totally your own way. Anyone is free to do so.

So, why don't we and instead all wait meekly for the next update of tool x or product y? In essence its shortage of time! It is this shortage of time that forces us to do with the available tools, there is no time to develop the right ones, never!
If you're in the first half of your life, don't accept this! Don't! No way, never!
And if you're in the second half of your life, be glad you learned to accept it. Twisted Evil
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mosc
Site Admin


Joined: Jan 31, 2003
Posts: 18197
Location: Durham, NC
Audio files: 212
G2 patch files: 60

PostPosted: Sun Mar 27, 2005 12:15 pm    Post subject: Reply with quote  Mark this post and the followings unread

LLR3 wrote:
Is there some hardware-wise comparable and affordable, well documented and user programmable equipment available? (I must have asked this before or was it in a dream!? Argh, maybe this all is a nightmare! Starting from scratch on a blank hardware platform!?... in a dark forest - WITH AN OWL!)

The Capybara hardware in the Kyma system from Symbolic Sound would be just the ticket. That is open. You can get in at any level including programming machine language for the DSPs if you want.

_________________
--Howard
my music and other stuff
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 12:16 pm    Post subject: Reply with quote  Mark this post and the followings unread

Rob wrote:
I think that if Alan Turing was still alive he would have loved the G2.


I strongly suspect he would have cursed at the zero page memory a lot and occasionally have remarked that real time does not need to be a good idea at all.

:¬)


Of cource removing those does not realy fix it since the universe does not have enough space or energy for a real Turning machine, but like with any fantasy; that need not matter that much, what matters is when we bump into the limits.

Actually, did Allan even like music? I think it´s Ada Lovelace who would´ve been into it.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 12:24 pm    Post subject: Reply with quote  Mark this post and the followings unread

LLR3, why don´t you simply install Pure Data, Super Collider and Csound (all free and mostly open)?
_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mosc
Site Admin


Joined: Jan 31, 2003
Posts: 18197
Location: Durham, NC
Audio files: 212
G2 patch files: 60

PostPosted: Sun Mar 27, 2005 12:54 pm    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
LLR3, why don´t you simply install Pure Data, Super Collider and Csound (all free and mostly open)?


I think KeyKit should be in this list too. http://nosuch.com/keykit/

_________________
--Howard
my music and other stuff
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 1:12 pm    Post subject: Reply with quote  Mark this post and the followings unread

looks nice, Mosc! I´m not sure it´s usefull for LLR3 but it might be something for me. I realy like the b&w interface too.

Thanks.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
LLR3



Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland

PostPosted: Sun Mar 27, 2005 1:12 pm    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
LLR3, why don´t you simply install Pure Data, Super Collider and Csound (all free and mostly open)?


I come from the land of non-realtime audio synthesis and refuse to go back EVER! Non-realtime operating systems on conventional CPUs will never be the platform I want to run my audio on. I want real dedicated DSP hardware and will not accept any substitutes! (Yes I know there used to be a special version of CSound for some proprietary DSP hardware, but is there anything left of that project, that I do not know...)

I wonder though if the new Cell processor will make all DSP hardware obsolete. I kind of like the idea of replacing all my studio gear with a single Playstation 3...

*LLR3
Back to top
View user's profile Send private message
mosc
Site Admin


Joined: Jan 31, 2003
Posts: 18197
Location: Durham, NC
Audio files: 212
G2 patch files: 60

PostPosted: Sun Mar 27, 2005 1:22 pm    Post subject: Reply with quote  Mark this post and the followings unread

LLR3 wrote:
I wonder though if the new Cell processor will make all DSP hardware obsolete. I kind of like the idea of replacing all my studio gear with a single Playstation 3...

Sooner or later this is inevitable. Whether the Cell Processor is the anwer remains to be seen. If it is, then that may be the opening for Linux.

_________________
--Howard
my music and other stuff
Back to top
View user's profile Send private message Send e-mail Visit poster's website AIM Address
LLR3



Joined: Sep 10, 2004
Posts: 41
Location: Helsinki Finland

PostPosted: Sun Mar 27, 2005 1:41 pm    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
looks nice, Mosc! I´m not sure it´s usefull for LLR3 but it might be something for me. I realy like the b&w interface too.

Thanks.


Well actually I´ve been using KeyKit for quite some time! KeyKit is a really nice system, albeit a poorly documented one (actually I´ve been documenting the core system for my own purposes). KeyKit could actually solve most of my problems if only there was considerably more bandwidth available over MIDI! (MIDI being pre-historic technology isn´t really Tim Thompson´s fault...)

*LLR3
Back to top
View user's profile Send private message
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 3:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

PD and SC actually run realtime, if non-realtime operating systems are a problem for you then you could look for a PD port for BeOS? OS/2 is realtime too but less used for audio. There are vst versions of Csound too, though that´s aparently a bit rag-tag while we wait for the new canonical version of Csound. I´m not aware of any realtime operating systems that support standard plugin types though. This is no big deal to me, but perhaps you need realtime performance for some sort of artistic reason.

I share many of your concerns, actually, and I believe "real" dsp hardware to be a dead end. The chips aren´t getting any faster lately and won´t without fans. The G2 is the most advanced "real" hardware thing out there and as I remarked elsewhere in the past; for the most part I don´t considder it suitable for writing music on at all. Perhaps future revisions of the O.S. will fix this.

The problem with "real dsp hardware" is that it´s inherently conservative and aimed at the people who believe routing oscilators to filters is "a idea", if I can paraphrase you. That´s understandable, those companies need to make money too.

Pick your battles, see what your realy need. If you realy have new ideas you need right now it might pay to code those up, then interface them to off the shelf toys for the rest. you can´t have something that´s uniquely for you, then have it ready made in harware at the same time. not on a finite budget anyway......

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sun Mar 27, 2005 4:26 pm    Post subject: Reply with quote  Mark this post and the followings unread

[quote="LLR3"]
Kassen wrote:

I come from the land of non-realtime audio synthesis and refuse to go back EVER!


I never realy tried non real time tools for making music (and I probaly won't), but I do know my noodles would be inpossible to make without real time synthesis.

What you wrote about the impossibility to make model based music with the G2 seems to the point to me.

The G2 implements a simulation of an anolg synth and then on that simulation we should try to simulate another model. It's kind of sillly to want to make models this way.

A computer, what the G2 actually is, should support models in a more direct way, like with a programming language (and I don't care of what sort it is, as long as it's efficient at run time with both memory and time).

Jan.
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 4:39 pm    Post subject: Reply with quote  Mark this post and the followings unread

Erm, something is going wrong, Jan. I´ve lately been arguing realtime is over-rated and am in fact moving towards less and less realtime use, only using realtime when conventient compositionally. LLR3 wants realtime.

I´m not realy sure what "models" you are refering to. Are you speaking of physical modeling or about abstraction layers?

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sun Mar 27, 2005 5:30 pm    Post subject: Reply with quote  Mark this post and the followings unread

Kassen wrote:
Erm, something is going wrong, Jan. I´ve lately been arguing realtime is over-rated and am in fact moving towards less and less realtime use, only using realtime when conventient compositionally. LLR3 wants realtime.

Well I'm glad to hear you think you're going wrong here ;-) (**1)

Seriously though, we might have a disagreement then & here, but I can't see anything going wrong yet. What works for you maybe doesn't so for me at this time but it might at a later or earlier time stage (and so it's interesting to read your writings about this)
Quote:

I´m not realy sure what "models" you are refering to. Are you speaking of physical modeling or about abstraction layers?

Yes, sloppy, I was thinking not about physical models but more about compositional models. Like in layered or nested rule based music. Like lets say I have table that I want to program symetrical variatons on for small time scale, and I want some self similarity on a larger time scale, and I want to play random notes, but they should fit a model, maybe a Markov thing, etc ...

Things like that tend to get ugly on the G2 (on the classic as well or even more so) unless you go with the system as it is, but that isn't as straight forward as it could have been. But still hard to comprehend by looking at the patch.

The things you'd like to call in Lisp for, I guess ?

Jan.

(**1) I know you didn't write that, Frisan humor I guess.
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 7:33 pm    Post subject: Reply with quote  Mark this post and the followings unread

Yes, I meant that your quote went wrong. I´m realy not going in the wrong direction with currently shying away from realtime, or even one directional, linear time. I have some very good and compositionally sound reasons for this, i´ll write on those later once I have my sollutions sorted out better so it doesn´t sound like I´m using to much lsd.

About modeling; I have Tassman.... That kinda sorts the issue for me, Tassman is not perfect but it does specialise in modeling and it sounds marvelous. In fact I´m currently working on a fairly complex piece that contrasts digitally glitchy G2 sounds based on phsyical modeling ideas against realistic if imaginary instruments in Tassman. The contrast is quite large, both are of cource valid but the G2 tends to go towards harsher textures in that area very quickly because it´s not nearly as well suited to ballancing out delicate feedback loops. I´m increasingly understanding why the ircam school of thought insists on floatinging point; it realy makes a lot of difference for feedback based systems, not only in the sound generation section but also in the control part.

This means I´m using the G2 with a lot of explicid controll and trough a lot of guitar effects and it comes out harsh and chaotic sounding while realy quite comparable ideas in Tassman get their controll from just some note data and some audio in and use a fairly advanced control structure to adapt to the situation and on their own come up with textures that keep morphing in intuitively sensible ways. Different aesthetics but both are valid and the contrast is nice. If I only got to model on one platform then the choice is easy. Then again, if I only had one platform for rapid testing then the choice would also be easy....

Lisp, to me, is a matter of power and being used to trying to solve next to anything using recursion (because that´s realy easy once you only solve a slightly simpler case using recursion, you see). Like I wrote; I´m not sure exactly what we´d use scripting for but if we are going to have it we should have a powerfull system. To me having recursion and Labda and so on means anything that could conceivably require solving could be solved... I dunno, analysis of playing styles to adapt presets would be nice? Automatic beatmatching would be fun too, Perhaps more algortimic composition.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 7:36 pm    Post subject: Reply with quote  Mark this post and the followings unread

Whoops, misread you note on what models you wanted. I should have a different ratio between the number of things I do and the hours of sleep I get.

Yes, lisp is good for that. I´m keeping up the rest of what I wrote since it might be interesting, if off topic, to some.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
blue hell
Site Admin


Joined: Apr 03, 2004
Posts: 24079
Location: The Netherlands, Enschede
Audio files: 278
G2 patch files: 320

PostPosted: Sun Mar 27, 2005 8:23 pm    Post subject: Reply with quote  Mark this post and the followings unread

It's ok to vary ratios.

Or to go off topic.

My personal wonder language is Forth.

I came to page six of the lamba calculus / functional programming reader, about 10% into it ... eenough to get the idea, but I lost count on nesting levels & proofs of correctness thereafeter.

Lisp, as a functianl programming environment, is not very suitable I think for the average programmer, but it's deep, basically very simple yet mind boggling. Not too hard to implement I guess, but I wouldn't know how well it maps onto a DSP.

I could say about the same about Forth, but where Lisp is theoretically founded well enough to allow for power Forth would be open enough to alow for that power to be programmed.

Forth is more of a hackers aprooach I think. I love it for embedded systems, but for the G2 ... well it would be my first go when I'd have to implement someting .. as I've implemented several Forth systems for various processors.. but for the G2 ...

I never built a Lisp thingy though ... maybe I should try some day.

To bne reall ... both systems are too far from average programming I fear to stand a chance on hnte G2.

Jan.
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Sun Mar 27, 2005 10:31 pm    Post subject: Reply with quote  Mark this post and the followings unread

Lisp has some realy nice features that make it the tool of choice for solving problems by simply defining when they would be solved and turning your head inside out. If Forth is for hackers, Lisp is for magi, it introduced some realy interesting things to the world like allowing variables to be anything, including code.

The history of Lisp is actually realy facinating, if I remembver correctly it started out as a thought experiment, a imaginary programing language in which for reasons that momentarily escape me, the need was felt for a instruction -written in that language- that would evaluate expressions in that language. This was a nicely selfreferential joke untill a student of the professor who wrote the article actually implemented that bit of code.

Boom.

Now, C compilers get written in C but the *first* C compiler obviously was written in something else, for Lisp this order was arguably the other way around; Lisp got defined in Lisp. That alone should be enough, I think. :¬)

The general consensus is that Lisp is completely unusable and should be avoided at all cost but in the meantime everything else has slowly been absorbing elements of Lisp.... Actually I never actively used it, I did learn to program in Prolog which shares a lot of Lisp´s ideas, enough for me to be able to read texts on Lisp and go "yes, of cource" all the time. I heard Prolog can be expressed in just 70 lines of Lisp so....

The one problem with these things is that using them makes your brain feel like it´s being turned inside out while they do permanent damage. For example, the first thing I did with Rob´s feature list was make sure I could have recursion by abusing some things (admittedly I asumed his switch could also go backwards), when I figured that one out I tried and build a crude Lambda from that (I sorta kinda asumed I could make arrays grow in sise by adding to them too), then I sat back feeling at ease. That´s of cource not a healthy reaction to have to new sugested scripting systems, if I have those things I considder everything solvable and will wander off to do something else, not bothering to do anyhting with it for now.

Ok, back to my current project.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
jksuperstar



Joined: Aug 20, 2004
Posts: 2503
Location: Denver
Audio files: 1
G2 patch files: 18

PostPosted: Sun Mar 27, 2005 10:35 pm    Post subject: Reply with quote  Mark this post and the followings unread

Hmmm. I don't see the need for specialized DSP hardware these days. A 2GHz "conventional" processor these days has enough DSP-like technology (level 1 cache instead of the local RAM, 32-bit floating point pipe-lined math, etc). The bandwidth of these behemoths is begging for something more than a word processor or DVD player!! Hence all the movement onto PC platforms of the music and video biz.

However, for a *dedicated system* doing simple tasks, DSPs are killer. But the differences that seperate DSPs from CPUs is fading, and soon there will be very few products categorized as one or the other, aside from specialized applications. It's been an increasing trend..MMX, SSE2, DSPs with memory management units, etc. Choosing a proper OS, and enough bandwidth to meet your application, and you would never know the system is running on one or the other.

And for a simple scripting system, I don't think the G2 is well suited for LISP. It doesn't have proper memory management, nor nearly enough RAM to handle the recursion you'd like Kassen. But, my guess is the G3 will have floating point processing and 1gb of RAM. Just my theory, though.

I do agree, the G2 could use some more "differentiation". It is very cool, but still has, as Jan pointed out, some shortcomings, since it tries to ALWAYS model analog. Some things are just better done in the digital world, and a few modules that acted that way would go a long way in doing things on a "modular" in real-time with little effort and less DSP resources.

Three cheers for OSC over MIDI...now THAT would open up a PC<->G2 combo for better real-time composition.
Back to top
View user's profile Send private message Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Mon Mar 28, 2005 11:32 am    Post subject: Reply with quote  Mark this post and the followings unread

First of all, a minor nitpick; we are *not* going to have OSC over MIDI, that would eliminate all of the fun bits because midi is reeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaallllly sloooooooooooooow. What I proposed and what Rob wants on "the list" too is tunneling OSC through the USB cable, probably using the space reserved for the three other G2´s you might get. This would open the way for all kinds of fun stuff, especially if people would follow my sugestion for identifying the source or destination voice of data with a extra "tag". Netto the result would be that the G2 install claims it´s a ethernet port in adition to the "game controler/audio/blah balh" it´s already claiming to be. We could then write data to that port that would end up in a yet to be designed module. This would bypass the shortcomings of midi, particularly data resolution and the fact that most midi controlers are monophonic. It would also instanly turn the G2 into a OSC controler for programs that can use one though admittedly then we are still stuck with the encoder´s resolution.

This would instantly rocket Clavia to the cutting edge of technology because nobody else is having OSC controled consumer hardware at the moment. We could then use this to point out to sequencer manifacturers that they are lagging and spare our grandchilderen the suffering that is MIDI. Maybe.

I agree with much of your other thoughts, they are quite reasonable (though I suspect Clavia won´t go floating point). There are also a few more "digital" style modules then you imply, there are shift registers, gates, clocked delays and so on, I kinda like those, the random modules have also taken on a digital additude towards randomistation, but there could be more. If we just had a adressable array we could do grains.

While we are talking about this stuff anyway; what makes no sense to me is that the only way to have a patch spawn voices in another patch is through MIDI. There is realy no reason to be limited by MIDI here.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Kassen
Janitor
Janitor


Joined: Jul 06, 2004
Posts: 7678
Location: The Hague, NL
G2 patch files: 3

PostPosted: Mon Mar 28, 2005 12:08 pm    Post subject: Reply with quote  Mark this post and the followings unread

First of all, a minor nitpick; we are *not* going to have OSC over MIDI, that would eliminate all of the fun bits because midi is reeeeeeeeeeeeeeaaaaaaaaaaaaaaaaaaaallllly sloooooooooooooow. What I proposed and what Rob wants on "the list" too is tunneling OSC through the USB cable, probably using the space reserved for the three other G2´s you might get. This would open the way for all kinds of fun stuff, especially if people would follow my sugestion for identifying the source or destination voice of data with a extra "tag". Netto the result would be that the G2 install claims it´s a ethernet port in adition to the "game controler/audio/blah balh" it´s already claiming to be. We could then write data to that port that would end up in a yet to be designed module. This would bypass the shortcomings of midi, particularly data resolution and the fact that most midi controlers are monophonic. It would also instanly turn the G2 into a OSC controler for programs that can use one though admittedly then we are still stuck with the encoder´s resolution.

This would instantly rocket Clavia to the cutting edge of technology because nobody else is having OSC controled consumer hardware at the moment. We could then use this to point out to sequencer manifacturers that they are lagging and spare our grandchilderen the suffering that is MIDI. Maybe.

I agree with much of your other thoughts, they are quite reasonable (though I suspect Clavia won´t go floating point). There are also a few more "digital" style modules then you imply, there are shift registers, gates, clocked delays and so on, I kinda like those, the random modules have also taken on a digital additude towards randomistation, but there could be more. If we just had a adressable array we could do grains.

While we are talking about this stuff anyway; what makes no sense to me is that the only way to have a patch spawn voices in another patch is through MIDI. There is realy no reason to be limited by MIDI here.

_________________
Kassen
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic Moderators: Nord Modular Editors
Page 1 of 2 [29 Posts]
View unread posts
View new posts in the last week
Goto page: 1, 2 Next
Mark the topic unread :: View previous topic :: View next topic
 Forum index » Clavia Nord Modular » Wish List
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Forum with support of Syndicator RSS
Powered by phpBB © 2001, 2005 phpBB Group
Copyright © 2003 through 2009 by electro-music.com - Conditions Of Use