Structured busses

infuzion · 4 Jan 2010

mwvdlee wrote: I have a nice mock-up that demonstrates this idea, but since we can't attach anything in this subforum, the explanation will have to do.

I think we use the Examples or Help forums for attachments now. BTW, I think we don't need extra primitives for this idea, since you can already add Bus links together, to make a "Mega-bus", & just label the links L-Vol,L-Pitch,R-Vol,R-Pitch, etc from the start.

trogluddite · 4 Jan 2010

I like the idea. 🙂 My only worry is that at the moment, the busses are very clunky in the way they work. It's a shame coz I love the idea of them - but I ended up taking them out of my last project - they seem to take ages to iniialise if you have a lot of them, and it made a horrible noise out of my speakers while doing it! I like the way that they are dynamic though - the names aren't fixed like the normal connectors, you can change the bus names string input while the code is running for some really dynamic switching. And they sure as hell make big schematics easier on the eyes (and brain!)

The Luddite

mwvdlee · 4 Jan 2010

I already noticed the adding of busses, but having to prefix every individual keyname of a bus is a lot more messy than if you could just select an entire child-bus from a parent-bus. I dont know how the busses are implemented internally, but if it would be easy to implement, it is certainly a feature I would like to have.

trogluddite · 4 Jan 2010

Something like the way folder trees work maybe. You could then possibly extract just one connection within a child bus by using a bus extract with the string 'Child/Parameter1'. The way I do this (sort of) currently is to use a string adder to add an index from an Integer primitive to the main part of the name. Your way would be far more flexible though, and make schematics much easier to read!

infuzion · 5 Jan 2010

mwvdlee wrote: I already noticed the adding of busses, but having to prefix every individual keyname of a bus is a lot more messy than if you could just select an entire child-bus from a parent-bus. I don't know how the busses are implemented internally, but if it would be easy to implement, it is certainly a feature I would like to have.

I would say the prefix is a good programming practice in general, since you have 2 similar but not the same information, you need to track their difference. Naming things the same that can be confused easily is not a good habit.

If you follow the link I provided, you'll see a perfect example how you can select a sub-set of buss items quickly & effectively.

I'm not saying your idea is bad, it is a neat idea, just that is can be done with what you have now. The very little part-time time the only SM programmer has can be used more effectively IMHO. A year ago Malc was working on a secret new primitive, & I provided a more flexible & faster solution using only existing primitives, so I said, "Sorry, but don't need it. We need fewer crashes though!"

mwvdlee · 5 Jan 2010

infuzion wrote: I would say the prefix is a good programming practice in general

I disagree. It's a crutch you need when you don't have a better way to separate fields. I'm not talking about "similar but not the same". It is in fact the same information (albeit with different values); just like synchronized modules basically.

infuzion wrote: If you follow the link I provided, you'll see a perfect example how you can select a sub-set of buss items quickly & effectively.

The link, though a nice trick, shows a schematic riddled with wires. The whole point of busses is to rid of wires. Besides, it doesn't really deal with what I'm trying to achieve, which is arranging busses in a sort of tree structure.

I agree there are more worthwhile things the SM programmer can do on SM, but I also have a hunch that this might just be a very simple thing to implement; assuming the busses are just standard C++/C#/whatever key-value containers, it would be trivial to use a bus as the value for a key-value pair.

infuzion · 5 Jan 2010

mwvdlee wrote: I agree there are more worthwhile things the SM programmer can do on SM, but I also have a hunch that this might just be a very simple thing to implement; assuming the busses are just standard C++/C#/whatever key-value containers, it would be trivial to use a bus as the value for a key-value pair.

There have been a few modules I've & others have made that were made into primitives, Counter Advanced comes to mind, so primitives are handy. Though if you don't like my OSM-example's mess, put it inside a module, skin it, & never open it again. 😉

Anything new in SM is almost never "simple", since (in Malc's more or less own words) adding anything has to be tested against the interaction of all the other modules. Plus the Bus system was never "simple" to add either, it took years, & Imean years before the Bus system was more or less bug-free, & the lack of connector-type updates for the Bus Extract is still a bug IMHO. So yea, maybe a day to add it, & weeks & maybe months to test & debug it. Lockable modules, requested like 4.5 years ago, with 2 attempted tries to add it, still is not part of SM, though I thought that was simple to add also In summery, it is best to assume that any addition will be not simple to add. Maybe if we're lucky it will be, I wouldn't bet on it.

Also, think that you're adding to the DLLs, which are already overbloated IMHO with unused primitives. Adding more features will increase the size & (more importantly) loading time of VSTs.