Closed DerouineauNicolas closed 6 years ago
I think we should store the state of the sequencer. Because you never know, you could have a lot of actions that are then cancelled. You cannot store all of them after months.
So I propose to create a state sequencer json which stores: tempo, tracks, activated steps.
I tried to store the state of the sequencer (tempo and selected pads) in a json object into the function toggleSelectedListener().
The state is updated whenever a client click on a pad.
This is meant to send the exact real-time state of the sequencer to the server, which then broadcast it to every new client.
The problem is when you deselect a pad previously selected, the pad "selected" in the json object must be erased.
I think it is better to store the sequencer state in the server. This way socket are lighter and we avoid problems of transmission for instance.
The idea of using a json object for storing the sequencer state seams nice. Something like that:
{
"room_id": <room_id>,
"tempo": <tempo_value>,
"pads":
{
"kick": [<list_of_activated_pad_ids>],
"snare": [<...>],
"hihat": [<...>]
}
}
In the future, we will add other fields. For instance about the audio sources (when we will browse sounds from freesound).
The sequencer state is now stored in a JSON object on server side
Tempo is now added to the 'message' (minor change on app.js on how to get instruments)
There is a bug to correct : sometimes when selecting multiple pads of the same track, when you deselect one , there are more than 1 pad deselected (only in the state). This is due to the for loop I guess
I'll work on the broadcast of the actions to the clients
Whenever a new user connects, pads should be activated with the actions already activated on other clients.
Should actions be stored on the server ?