connecting a source to multiple destinations

jorge · 19 Feb 2005

The poly schematic you're using for playing a sound shouldnt be shared with the analyser, at the moment it doesnt work. The sound you hear will correspond to the notes you play, the graph the analyser shows corresponds to running the sound code once.

The analyser runs the compiled code for a specified number of samples, it doesnt keep running it all the time, so if you started the analyser and then you played notes, you'd have to make the analyser run for a long time to actually see the notes you played, that's not really the purpose of the analyser and to look at the notes you play there is another more appropriate component called PolyToGraph. I cant remember if that component is in the latest released version but if you're interested I can send you our latest internal executable with all the latest alpha and beta components but you'd be using it at your own risk.

There are situations in which I want to hear the sound at the same time that I see a wave from the analyser, the current way to do that is to create a copy of your sound module ( or even sync copy it ) and set the one used by the analyser to have a fixed frequency and use the other connected to the MidiToPoly.

If you find my explanation confusing, I'll post a screencapture next time.

If you have suggestions to how you think the analyser should work let me know too, specially how would you deal with the fact that the analyser needs to run poly schematics with a fixed frequency and the sound you hear corresponds to the notes you play.

NothanUmber · 19 Feb 2005

Thanks, I found the "Poly to Graph" module (crashed SM the first time I connected it to a wave display but that bug was not reproducible, next time everything worked fine). Obviously the interaction of the modules is a little bit more complicated than I initially thought. From a naive kind of view one could expect, that one module takes all it's input values into account, computes an output and then passes that to all it's predecessors etc. Obviously that doesn't seem to be the case in SynthMaker: E.g. the Poly2Graph module only displays graphics if it is part of a chain that leads to an output, so midiin->m2p->sine->poly2Gr->{poly2mono->{XLeft,XRight},waveDisplay} works but midiin->m2p->sine->poly2Gr->{poly2mono,waveDisplay} doesn't. Could it be, that the actual code is only generated at certain modules (e.g. xLeft, xRight and analyzer) and thus can my previous problem be reduced to the fact that only one of these "end consumers" is allowed in a chain at one time?

Greetings, NothanUmber

P.S.: I don't understand why the analyzer only works with fixed frequencies. Wouldn't an analyzer with a samplecount of e.g. 44100 samples that is triggered at a specific point of time and connected to an arbitrary "live" 44.1 kHz audio stream give me the same results as if I would record the same second of that stream with some hd-recording software and watch the resulting graphical representation in it's wave track?

jorge · 19 Feb 2005

NothanUmber wrote: Thanks, I found the "Poly to Graph" module (crashed SM the first time I connected it to a wave display but that bug was not reproducible, next time everything worked fine).

Well, the PolyToGraph is still a beta component in a beta version of SM, but its very useful to know. My guess is that it probably crashes when either the Poly input or Poly output are not connected. If you can reproduce it let me know, feel free to post any crashing schematics to [email removed] .

NothanUmber wrote: Obviously the interaction of the modules is a little bit more complicated than I initially thought.

Your feedback is very useful in relation to that, so keep it coming please.

NothanUmber wrote: From a naive kind of view one could expect, that one module takes all it's input values into account, computes an output and then passes that to all it's predecessors etc.

Different types of connectors work in different ways. Poly connectors are not really data, they're just a graphical way of defining machine code, machine code runs inside the PolyToMono component for example. The actual code is re-linked each time the schematic changes. Most messages flowing through the Poly connectors are related to Allocating memory, Initialising memory and Compiling/Linking machine code. What you might lose in terms of simplicity you gain in very fast performance. Having said that there are still ways to simplify things, for example, I agree with you that maybe the PolyToGraph should work even without having to be in the middle of a poly path, maybe it should just have a Poly input and a graph output. Another example is the Green connectors, they work with triggers that are sent left to right each time data changes and GetFloat, GetInt, GetString etc calls going from right to left to get the new values. This system is obviously too slow for real time sound processing as it has loads of function calls but it is good enough for GUI interaction and calculations that only happen on value changes. Midi flows left to right just passing the status, channel, data1 and data2 values as parameters. etc etc

NothanUmber wrote: Obviously that doesn't seem to be the case in SynthMaker: E.g. the Poly2Graph module only displays graphics if it is part of a chain that leads to an output, so midiin->m2p->sine->poly2Gr->{poly2mono->{XLeft,XRight},waveDisplay} works but midiin->m2p->sine->poly2Gr->{poly2mono,waveDisplay} doesn't.

Exactly, that can change though, not too hard to make it work without being part of a chain. Probably not the highest priority at the moment but your kind of feedback is what makes us change priorities. Specially if you insist on it and mention it again 🙂.

NothanUmber wrote: Could it be, that the actual code is only generated at certain modules (e.g. xLeft, xRight and analyzer) and thus can my previous problem be reduced to the fact that only one of these "end consumers" is allowed in a chain at one time?

Yeah, you're correct, but like I said before, that can change.

NothanUmber wrote: P.S.: I don't understand why the analyzer only works with fixed frequencies. Wouldn't an analyzer with a samplecount of e.g. 44100 samples that is triggered at a specific point of time and connected to an arbitrary "live" 44.1 kHz audio stream give me the same results as if I would record the same second of that stream with some hd-recording software and watch the resulting graphical representation in it's wave track?

Yeah, if you set the analyser to a high enough number of samples, you should even be able to see the notes you play if you're quick enough to play them very shortly after the trigger. I dont recommend you do that anyway, the purpose of the analyser is to analyse bits of machine code, to look at the graph it generates, clock-cycles and the disassembled machine code. There will be components to be used for SoundBuffers, that work is half done and shouldnt take too long. Graphs are not meant to be big, at the moment, when you display a Graph in a Graph Display, all the lines/points are drawn which gets really slow when you have a huge number of points like 64K for example. These issues you mention need to be sorted, more from a user point of view as the code itself is not too hard, so your opinion as a user is very welcome.

NothanUmber · 20 Feb 2005

jorge wrote: Well, the PolyToGraph is still a beta [...] crashing schematics to [email removed] .

Haven't been able to reproduce it (tried some combinations) but I'll write you if it should be the case.

jorge wrote: Different types of connectors [...] values as parameters.

Interesting, thanks for the insights! If it is not too difficult to implement it could be very helpful for the user to give him the "illusion" of that mentioned black box "pass inputs to the module and wait for an output at the other side" concept as it is very intuitive and easy to comprehend. That should be the case if every component that establishes a connection to the outer world (audio out, midi out, vst wrapper etc.) on the one side and everything that provides visual feedback inside SM (e.g. the different displays, data components, gui etc.) on the other side always get a signal if they are connected. (That perhaps means that you would have to allow multiple "code generators" and make every polyToWhatever converter such a component). That way users that presume the "black box semantics" wouldn't even notice the special optimizations for different signal paths. (A later chapter in the docu could offer some further insights e.g. to put advanced developers into the position to decide which conversions are performance wise "expensive" - despite that it is interesting to read about innovative techniques) Another loosely related observation: In order to make it even easier to guess which modules can be connected to each other and to make the filters more useful it would possibly more intuitive to forbit "implicit casts": Perhaps you could display input connectors that accept more than one signal type in multiple colors (and show them at multiple filter settings in the toolbar) or simply provide dummy converters if that convertion is always allowed.

Greetings, NothanUmber

jorge · 20 Feb 2005

NothanUmber wrote: If it is not too difficult to implement it could be very helpful for the user to give him the "illusion" of that mentioned black box "pass inputs to the module and wait for an output at the other side" concept as it is very intuitive and easy to comprehend.

It might not be possible to have that simplicity together with 1 sample at a time processing with high performance. For example, the following schematic can be used to analyse the frequency response of a filter:

The compiled code inside the analyser runs each time you change the freq/res parameters, that means it can run a lot faster than sampling rate and a lot slower too, can even not run if you dont change freq/res. If the poly schematic being analysed was at the same time part of the sound you're listening to, they'd be running at different rates and wouldnt be able to use eachothers last calculated sample.

The way around would be to replicate that part of the schematic in a transparent way that the user wouldnt notice but I still dont know how to deal with the issue that the schematics being analysed normally need fixed input frequency/velocity etc.

NothanUmber · 21 Feb 2005

jorge wrote: The way around would be to replicate that part of the schematic in a transparent way that the user wouldnt notice

Yes, that could also be a good idea e.g. for several audio outputs etc. (Perhaps by generating code for all these "end-points" and then use some kind of multitasking to run all of them in parallel.)

jorge wrote: but I still dont know how to deal with the issue that the schematics being analysed normally need fixed input frequency/velocity etc.

Hm, the only nondeterministic things should be the inputs?!? Couldn't one have some kind of global debug-switch that e.g. creates a defined sound at the audio in, a specific note at the midi in etc. and activate the analyzer only in debug mode (while the sound component is only enabled in normal mode)? Then one could place analyzers at many interesting places directly in the normal sound chains for debugging purposes and wouldn't have to care about performance drops in normal mode on the one side and always have defined, reproducable conditions on the other one.

Greetings, NothanUmber

stefan · 21 Feb 2005

Imo, using syncronized modules isn't that much of a big deal. If you want to do it on your whole schematic, just make your whole effect/synth a module (what I usually do atleast, one wants to be able to export it etc), then copy this module and paste a syncronized version of it but connect fixed inputs to it instead of the midi (or audio) and connect the output to an analyser. From there on, everything you do in your schematic will be analysed in the synced version of it.

It's good enough for me anyway 🙂 And for a lot of purposes, using a vst spectral analyser or oscilloscope (smexoscope by bram @ smartelectronix for instance), will do for the real-time analysis.

NothanUmber · 21 Feb 2005

stefancrs wrote: just make your whole effect/synth a module [...] your schematic will be analysed in the synced version of it.

Your approach has the advantage, that one doesn't have to add a new mode and thus possible confusion ("Why don't I hear anything" or "the analyzer does nothing at all"...). Perhaps one could add a debug icon to the modules (beneath delete, set name, move into etc.) that automatically creates a setup like that you mentioned e.g. for a given midi->poly-module in a new schematic (e.g. one constant input for every input slot, an analyzer with trigger buttons and a data field that defines the sample length at the output etc. Perhaps one could even define "unit test templates" with custom debug constructions that should be used for certain module types (e.g. a debug template for modules with at least one poly out and a midi in, one for midi to midi or poly to poly etc.)

stefancrs wrote: And for a lot of purposes, using a vst spectral analyser or oscilloscope (smexoscope by bram @ smartelectronix for instance), will do for the real-time analysis.

Thanks for the tip, I'll have a look at that.

Greetings, NothanUmber

NothanUmber · 21 Feb 2005

An additional idea how to generalize the "unit test" concept: One could provide a generic "wizard" template concept that allows you to define templates for every module. Then one can place that module in a schematic, click on a wizard-icon and gets a list of predefined schematics for that module. The first entries of that list could be templates that were specifically written for that component, the following ones are automatically generated from templates of other modules with the same inputs and outputs so one could create generic test environments etc. That way one could also provide nice "tutorial examples" for many modules in order to help users to see how they are used in context.

bManic · 2 Mar 2005

I really like these ideas..

Cheers! bManic