Further developments...

[muellmusik]

A few thoughts on next stages here. Things we need to consider:

• Polyphony
• How to make sequences of sounds and thus play music
• On what level do we want to make different events comparable, both internally (compare elements of an event), and externally (compare events sonified in the same way), i.e. what aspects should we be able to mix and match for sonification purposes

A related question is the interface. The PR I just did clarified this a bit for me, as I can see we will have different event types with different components. Here are a few interface ideas:

• have multiple synths with a column for each param, so top looks like attack1, sustain1, ... attack2, sustain2...
  • Pros: Maximumly flexible, can map any input to any output
  • Cons: Makes the interface very crowded, especially if we potentially want a synth for each jet/muon/etc. Foldable areas of the table could help with this.
• alternatively treat each component (jet/muon/...) as a synth, and give it a separate radio button collection. This would look like current master (post my PR) just that you would have more than one selection in each column (one per component)
  • Pros: Interface relatively simple, easy and intuitive to compare components
  • Cons: Lacks some flexibility
• Option to choose to sonify an event as either a 'chord' or 'sequence'
  • Pros: Nice option, easy to compare components within an event, easy way to make a musical sequence, provides polyphony
  • Cons: ?
• Have the ability to save and recall an event sonification scheme
  • Pros: Useful for a lot of things
  • Cons: Are there any? I think it's a no-brainer
• Have a separate sequencer tab where you can make sequences of saved event sonifications
  • Pros: Make some music, polyphony, sequencing fun for workshops
  • Cons: Could be a bit complicated depending on how flexible it is.

Personally I think I'm not so keen on the first option due to the mess potential, but think the rest are worth considering. Separate sequencer tab is the only really complicated one and could be lowest priority, especially if we can already have sequences within events and can recall saved schemes while playing. But what do you think? Should we get Tom in on this as well?

[tpmccauley]

I think the option where physics objects like jets, muons, etc. are synths is a good idea. As is next option where an event is the component. They are complementary though, no? Each event will have different content so if objects sound different then events will as well...

[muellmusik]

I suggest we go with these three initially, and worry about sequencing after/if there's time:

1. alternatively treat each component (jet/muon/...) as a synth, and give it a separate radio button collection. This would look like current master (post my PR) just that you would have more than one selection in each column (one per component)
   • Pros: Interface relatively simple, easy and intuitive to compare components
   • Cons: Lacks some flexibility
2. Option to choose to sonify an event as either a 'chord' or 'sequence'
   • Pros: Nice option, easy to compare components within an event, easy way to make a musical sequence, provides polyphony
   • Cons: ?
3. Have the ability to save and recall an event sonification scheme
   • Pros: Useful for a lot of things
   • Cons: Are there any? I think it's a no-brainer

Implementation-wise it might make sense to work on those in that order. Certainly the second should be dependent on the first.

@KonVas can you take 1. as I'll need some more days to finish my video stuff, and then can focus on this a little more? Is it clear what 1. means?

@tpmccauley how do you want to approach this? Add some basic event visualisation (which would be nice for the kids?) You could do something like we've done in some of our performance visualisations where you see which element is being sonified (e.g. it pulses or spins or something). Or could make a start on 3.?

[tpmccauley]

I will give some thought to what can be done vis-wise on a short-ish timescale. re: 3 do you mean saving the audio, the settings, or both?

[muellmusik]

I meant the settings

[tpmccauley]

@muellmusik OK. Will take a look.

[muellmusik]

One other question for next week: How shall we run this? Host on a server or installed on the tablets? If the former where?

[KonVas]

It's a Node JS app. You can have it running on a computer, mac Mini, laptop, whatever. Then other devices on the same network with a web browser can access the app by using the IP of the host computer something like 160.75.76.132:PORTNUM. Portnum is assigned when you run the app, you will get it once the app is running in terminal, something like this: App running at: http://localhost:3000/ So assuming I want to access this now from my phone I would do something like this: 160.75.76.132:3000 on the web browser.

[muellmusik]

Ah okay, so that might be a good approach. Easy to update if needed.

[KonVas]

I am trying to figure out how to make this:

• Have multiple synths with a column for each param.

I am a little bit conscious of time as I am not sure how to implement this, but I have done some research and it seems the best way to achieve this is by creating multiple instances of whatever synth.

[muellmusik]

I think the approach should be to have an array to store the synths we will use for this event.

Then we get the list of elements (jet or muon) and for each of these (i.e. in a for loop) create and configure the synth for that element.

Then play them, either in sequence, or as a chord.

We would also need to clean up the synths from last time, which should actually happen before anything else. So in pseudo-code:

for loop over synthArray { synth.dispose(); // clean up synths from last time we pressed play }

synthArray = []; // clean array

for loop over elements { make and configure a synth for each element }

for loop over synth array { play each synth }

Does this make sense?

On 4 Apr 2018, at 09:29, Konstantinos Vasilakos <notifications@github.com mailto:notifications@github.com> wrote:

I am trying to figure out how to make this:

Have multiple synths with a column for each param. I am a little bit conscious of time as I am not sure how to implement this, but I have done some research and it seems the best way to achieve this is by creating multiple instances of whatever synth. Thus, I am doing something like this but I am not sure this is exactly what we looking for.

'click #matrix-table': function(event, template){ var selected = template.findAll("input[type=checkbox]:checked"); var par = $(event.target).attr('class'); var fieldValue = event.target.value; var envelope = {}; var freqModifier = {};

        freqModifier[par] = specs[par](fieldValue, Session.get(par)[0], Session.get(par)[1]);
        envelope[par] = specs[par](fieldValue, Session.get(par)[0], Session.get(par)[1]);
        var freq = Object.values(freqModifier)[0];
        triggerSynth(freq);

        var Synth = new Tone.Synth({
            oscillator : {
                  type : 'fmsquare',
                modulationType : 'sawtooth',
                modulationIndex : 3,
                harmonicity: 3.4
            },

            envelope : envelope

        });

        console.log(`Setter `, freqModifier);
    }

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/KonVas/Ipsosboard/issues/2#issuecomment-378522444, or mute the thread https://github.com/notifications/unsubscribe-auth/ABQQ7fGN5QHGGGtIGwhyXdFYu4JrJnkSks5tlIRlgaJpZM4Sh5UH.

[KonVas]

Yes this seems to do the trick on the multiple synth creation. But for the event side, I don't understand how to separate Muon1 and Muon2 configuration tables because the code of the HTML is changed. If I make a selection for Muon1 e.g. trying to control the 'attack' and then another selection Muon2 'attack' it will update the same object. You can see the illustration of the problem below.

I think, the table has to be separated in subtables with associated IDs (Muon1, Muon2 etc.), So then using JQuery selectors we can browse these sub-tables using IDs for each Muon config, then get their data, then create the synth and add to the synth array as you suggested before.

[muellmusik]

So then using JQuery selectors we can browse these sub-tables using IDs for each Muon config, then get their data, then create the synth and add to the synth array as you suggested before.

They already have ids according to group. So for instance, "Muon-pt-attack-0", "Muon-phi-decay-1". The number on the end is the index of the element (muon or jet). Note that the number displayed in the gui itself is incremented by one for humans. So Muon 1 in the gui is 0. So each radio button has a unique id. Given the list of elements, and the list of synth params, we can determine exactly what to query.

The groups rb groups are similar, 'attack-0', 'attack-1', etc.

[muellmusik]

The groups rb groups are similar, 'attack-0', 'attack-1', etc.

Hmm, that should actually be 'Muon-attack-0', etc., but as we don't have any events that mix element types, that doesn't matter at the moment.