Synchronized elements vs. O-O programming (interfaces)

stefan · 23 Mar 2005

They are several instances, just using the same "class".

What would an interface be like in SM?

Why not use buses for binding connections together?

Tom7777 · 23 Mar 2005

The more modules used usually the more complex things can get and i guess it really depends on how complex one wants things to get. I think that better results are usually best with more wires and modules ect on a synth anyway. But programs like SM allows you more depth within things so a user can make custom edits to single units and use buses ect then group to modules to simplify things. Modular synthesis is not really a simple thing anyway i think and the more complex the more variations and orginal ideas can be created and usually better results 🙂

malc · 23 Mar 2005

Kitchen Sink wrote: Isn't the "synchronized" concept a bit bad programming? I mean, if synchronized elements are used as a kind of work-around to have the same object instance visible in several places. Are they the same instance, or are they really synchronized copies?

I see your point. You're saying that copying modules is the SM equivalent to copying and pasting code in C++ say - something that is generally regarded to be bad practice.

It's a fair comment, although one of the reasons why it's considered bad practice when programming is because changes need to be made in more than one place and more often than not something gets forgotton. This isn't the case with our syncing modules.

Kitchen Sink wrote: this font/label thing smells like a kludge that will later on collapse in a big unmaintainable mess.

I don't think it's a kludge. It's fairly straightforward really. The whole point of sync modules is to make things easier to maintain not harder.

That all said I can understand where you are coming from. At the moment SM has no concept of a class as such. Modules are more like functions than classes. So in fact SM is more comparable with standard procedural programming than object oriented programming.

Maybe we can look at introducing some object oriented concepts into the software. It'll need some thinking about though.

Kitchen Sink wrote: Currently, there are different types of plugs: integer, float, string, area, colour, font, ... But where does it end? IMO, things like area and font should definitely be compound interfaces. Like, if you have an interface called "Parametric EQ input" and many different types of modules that conform to that, it is very easy to let the user switch between different eq modules. But if there's a separate wire for each of the settings (type, frequency, gain, Q, signal in), it will be a lot messier.

As Stefan said, you can already do something like this using the Bus components. I'm sure this concept has room for further development.

Thanks very much for your comments.

Kitchen Sink · 23 Mar 2005

stefancrs wrote: They are several instances, just using the same "class".

OK.

What would an interface be like in SM?

Like a bus connection, i.e. a collection of connections, but without having to use explicit bus create and bus extract components, and manually typed list strings. Just like you can now select a bunch of components and make a module out of them, it should be possible to select a bunch of connectors and bind them into an interface. With some kind of show/hide buttons, it would be possible to show the individual connectors of an interface, without popping up yet another dozen component boxes and a web of connections, at the same time losing view of what I was doing.

Why not use buses for binding connections together?

*cough* hadn't tried them before *cough*

To try my EQ interface example with buses, I created two modules: "Parametric EQ Interface Create" and "Parametric EQ Interface Extract", which kind of work as interfaces. If I now add these to the toolbox, it's quite good already. 🙂 Now if only there was integrated support for making these automatically for any set of connectors in a module...

It's also a bit of a problem that module inputs and outputs are untyped. So my interface create/extract modules' inputs and outputs are untyped, too. Of course the recommended types can be written in the connector labels as text.

Maybe I'm only looking for some "in-place" editing here. It seems that most things are possible to do already with Synthmaker's components and connections (because they're so generic), but usually I have to open another view, another "window" (although it isn't a real Windows window), and lose what I had in view. The same problem has been with Cubase: you can't edit almost anything without opening yet another pop-up editor window or dialog. This makes working with it quite distracting.

stefan · 23 Mar 2005

Imo, it would be cool if you could select any number of connectors and choose "convert to bus", where it would also take the names of the connectors and use these names in the bus string input, automatically. Something for malc and jorge to do I guess, because this is how you usually end up doing it, but manually. Also to be able to make a selection and _add those connectors_ to an existing bus connector would be good.

Kitchen Sink · 23 Mar 2005

malc wrote: It's a fair comment, although one of the reasons why it's considered bad practice when programming is because changes need to be made in more than one place and more often than not something gets forgotton. This isn't the case with our syncing modules.

So synchronized modules have the same code and the same data, so... why have separate copies at all? I understand the situation, if there are no classes inside Synthmaker.

Btw, if each synced module has its own code, doesn't it make the CPU's code cache very inefficient? I used to do "sprites" with self-building code with my 286 (over a decade ago), and it was very fast, because the sprites' data could be put inside instructions as immediate operands, but with newer machines, that kind of "optimization" was very stupid because the CPU had a 0% cache hit ratio. 😉

At the moment SM has no concept of a class as such. Modules are more like functions than classes. So in fact SM is more comparable with standard procedural programming than object oriented programming.

Doing O-O in SM isn't that far, really. 🙂 By using bus connections as "object interfaces", it's possible to do a bit of polymorphism. It could even be possible to simulate base classes like this, by exporting triggers and everything from a "base class" module. (why would somebody want to do that, is another question)

Kitchen Sink · 23 Mar 2005

stefancrs wrote: Imo, it would be cool if you could select any number of connectors and choose "convert to bus", where it would also take the names of the connectors and use these names in the bus string input, automatically.

Yeah, but why is there a need for such a name list string in the first place... why couldn't the names be written where they appear. 🙂

It's great we can discuss these things when Synthmaker isn't in version 1.0 yet.

stefan · 23 Mar 2005

Because you can have connections within the bus that aren't connected at the bus create and/or bus extract. You don't need to feed all connections into a bus create, and you don't have to extract all connections from a bus extract.

This way, you can split the bus up both into two different extracts or into two different creates (going to just one extract) and so forth.

Kitchen Sink · 23 Mar 2005

With "Add connector" and "Remove connector" functions/buttons, perhaps? To the added connector's label you would type the name of the connection you want to create or extract. I don't see a problem here. The list string input is an odd way to specify connectors and their names, but at the same time the string input itself is pretty useless, don't you think?

This is what I meant with my "properties" suggestion, too. To have in-place editing of stuff. To be able to set some data values inside a module without opening the module.

stefan · 23 Mar 2005

The string input is, imo, a very convinient way to copy bus connections between different bus creators/extractors.

Kitchen Sink · 23 Mar 2005

It is a way to do that. At least it must have been very easy to add to the existing code. 🙂

But I began to think about the code cache issue. If Synthmaker doesn't have classes and objects, then basically there is not a single byte of code shared between any two parts of even a very large synth, right? This doesn't seem too good for cache performance.

stefan · 23 Mar 2005

Basicly any schematic is compiled into one whole function. No calls, everything is inlined. This ought to be cache heaven, since the coming instructions always are right after (in memory) the program counter.

Kitchen Sink · 23 Mar 2005

So do you mean that as long as the instructions are sequential, they are pre-fetched with zero performance hit, even if there's a megabyte of code?

I thought it could be better if each similar chunk of code had to be loaded into the CPU only once, because all of the code is executed many times in a row to fill the ASIO buffer.

Btw, how large amounts of memory are we talking about? How large is a big synth's code?

stefan · 23 Mar 2005

I've looked at the generated code for my synth, and I'd roughly estimate it's size to maybe 50-70kbyte. And yes, as long as you don't make any function calls / jumps, the cpu can prefetch code in the most efficient manner. But on most cpu's, the entire code should fit in the cache anyway.

Kitchen Sink · 23 Mar 2005

Actually I meant, how fast can prefetching be compared to 100% code cache hits? Can it be equally fast?

Anyway, if the "no calls, no branching" principle is carved into stone design-wise (?), then there's nothing to be done for it.