dktr0 / estuary Goto Github PK

WebDirt's playSample retains a reference to a newly created Graph for the sample but the only place this appears to be cleared in by stopAll which Estuary never invokes which means that the instance's playing array forever fills with Graphs. Maybe this should be a WebDirt issue or estuary should somehow clean up when done?

Without having booted ghcjs, I ran make clean from the github repo directory. This deleted some things from my root bin directory, including python.

It's possible to cause a divide by zero in Tidal notations. One likely case is when Time values of 0 are used in various places, for example: linger "0" $ efull 3 8 (s "tabla:3") (s "tabla:4"). Because of this we may need to catch and discard exceptions when rendering ParamPatterns (an uncaught divide by zero crashes the browser runtime).

(As a submodule it constantly generates dirty status in our git workflow.)

Hi David,
Testing out some of my own breaks samples tonight, and I've discovered that loopAt does not work as expected in estuary

It's like it's reading the sample as significantly longer than it is, jamming the sample into the early part of the loop, then leaving whitespace to the end.

Here's a little video comparison between the same samples in tidalcycles proper, and estuary - cps is set to 0.5 in both cases :

The upload seems to be having some issues playing back on my end, here's a youtube link:

https://youtu.be/jjCKxIkzk6w

eg. 3x8 is the same as 3_8. cause is that _euclidInv is erroneously defined the same way as _euclid in Togo.hs.

The LeaveEnsemble message in the top-level protocol doesn't seem to ever be issued anywhere. This will get in the way of counting clients in ensembles, and also will lead to some small wasted bandwidth when clients leave an ensemble without joining another one but keeping the client open still.

The theme styles select with a transparent background-color which is fine when the dropdown is collapsed but causes a white background when opened.

This should probably be set to a fixed color based on the theme (like black in the classic).

CC @luisnavarrodelangel for consideration in the css cleanup.

If the SSL certificates for a domain/server change/renew while the Estuary server is running, it will still be using the old certificates which may expire and then cause access problems. The server should periodically update the certificate data in use to avoid this (occasional) problem.

The issue seems to be isolated to Tidal's use of randomDouble from System.Random.Mersenne.Pure64. The following test code crashes the browser runtime (prior to and independently of any Reflex/Reflex-Dom stuff) - the PureMT value is correctly shown by the first putStrLn then everything crashes during the second putStrLn (which evaluates x using randomDouble):
do
mt <- newPureMT
putStrLn $ show mt
let x = fst $ randomDouble mt
putStrLn $ show x

Hi, I just tried to make a new ensemble for live coding with my friend from Argentina. But, whenever me or my friend couldn't create a new ensemble. The name doesn't pop-out on the list.

flatpat, ifp, and fmap idioms like "floor <$> ...some pattern..."

Hi, this is my first time with Estuary and i tried to eval a simple code like d1 $ s "bd" in Estuary solo mode but no sound coming out. I tried to check the tutorial, thinking that maybe i need to install something. But i only found the MiniTidal tutorial. So should i install something first before i use the Estuary? thanks.

Browsers often hold on to old versions of the client, sometimes even through indefinite refresh cycles. This leads to much gnashing of teeth.

There appears to be an ever growing delay that starts at 0 when the page is initially loads but increases as time goes on. The delay here, is the time between clicking the eval button and hearing the changes take effect.

As per https://developers.google.com/web/updates/2017/09/autoplay-policy-changes, I've just updated chrome to a version with this policy in effect and it has a pretty major issue for Estuary. From the home page there needs to be at least 1 user interaction to get to a page that plays audio so the issue is not that the context remains pause()ed but rather the clocks get way out of sync.

After the page loads, the audio context is in suspended state until there is a user interaction with the page. The renderer seems to be scheduling under the assumption that this clock is never paused and as such keeps counting up on it's internal clock. This delay between page load an first interaction seems to be the same delay between making a definition change and hearing the update leading me to believe that the internal clock is ahead of the audio clock by this duration.

I think the internal clock (used for rendering tidal patterns) should be occasionally synced to the audio clock. As such this is likely related to #15 but could potentially be a separate issue.

When using visuals are used in Estuary (e.g. via Hydra) the foreground and interface text can become illegible.

Can Estuary or one of its themes be adapted to have a translucent black background on the text? Something like what Hydra currently does.

This would greatly increase legibility

Would it be possible to support cps and/or setcps in mini-tidal? Changes of tempo are quite important for the gamelan music we are trying to code, and the set tempo box is not ideal.

When an anonymous participant enters the ensemble, the ensembleStatusWidget displays its text input, FPS, latency, etc. This is located in the file Estuary/Widgets/EnsembleStatus.hs

Hi.

I was researching (academic) information about Estuary (for citing it in my Computer Music lecture) and I found Ogborn, D., Beverley, J., Del Angel, L., Tsabary, E., & McLean, A. (2017). Estuary: Browser-based Collaborative Projectional Live Coding of Musical Patterns. Third International Conference on Live Coding.Available from http://iclc.livecodenetwork.org/2017/cameraReady/ICLC_2017_paper_78.pdf
(cited on https://www.concordia.ca/finearts/music/faculty.html?fpid=eldad-tsabary , that's just the first answer of the seach machine) perhaps you could add (a link to) this paper somewhere (README of this repo, or https://estuary.mcmaster.ca/ )

What is the relation to mini-tidal? I don't quite see it the paper, but am I right in assuming that you don't want to give users access to a real ghci session in their browser, so you've written an interpreter for: Tidal's mini language (in full) plus some subset of Haskell? what subset exactly? Is this solving the same problem https://github.com/jwaldmann/safe-tidal-cli ? I'm not suggesting my package is better - I just want to understand use cases and design choices. E.g., I need the full GHC API at runtime.

• J.

Hi David,

I was just trying to do some testing with stutWith, but I could not get it going in estuary. This works fine in tidal (proper):

stutWith 4 0.1 (* gain 0.8)
$ s "bd"

but throws the following error in estuary:

1:1 expected ControlPattern

We don't currently support browsers other than Chrome/Chromium anyway, so this issue is about the nature of the feedback when people try with Firefox. They should be told to use Chrome/Chromium instead.

It is very annoying (to say the least) to accidentally activate the browser's back functionality while in the middle of a performance!

because audio context is not being created in a way that works on Safari. So with this browser users don't get the helpful message that they need to use another browser...

eg. someone adds a sample to a reslist, but the reslist has already been loaded, so it is not re-loaded automatically.

This will probably be a huge performance sink in clients where, in a networked ensemble, a structure editor is primarily being edited somewhere else, as every little edit will result in a complete rebuild of the widget. It would be possible instead for each component of the structure editor to rebuild itself only as necessary.

Symptom in rehearsal (not clear whether accelerate was truly the culprit) were levels that stay beyond the clip point for a very long time (and so result in a click and long silence, then a click when the browser is completely quit).

This is likely a matter of two things: (1) separating things that use Tidal's functions into separate modules from the ones where we have types representing Tidal actions/notations, and (2) removing dependency on Tidal's tempo type.

So that in ensembles people don't have to set it to 0 to avoid overwriting previous zones' output

(In addition to an ugly error message in the console, it seems the failure to reconnect event sometimes causes audio glitches.)

terminal/view parser needs to be amended to permit this

The server seems to be hanging onto invalid connections (or something like that) leading to a symptom of numerous send exceptions that appear to accumulate and grow more numerous over time. Is something happening where web socket connections are dying but not being removed from the server's list of connections somehow?

Currently the server is compiling mini-languages because Estuary.Languages.TidalParser provides both a type for noting the choice of mini-language (required by the server) and a function 'tidalParser' which refers to the parsers in each mini-language module (this is not required by the server). These should be separated to remove the dependency and allow the server to be built more quickly.

because that mistake is very easy to make and sometimes hard to realize that you have made it.

Font also needs to be incorporated into progressive-with-retries loading system. Symptom is that Estuary appears with a "plain" font rather than its own font.

When running a solo with the webdirt box checked, there is no audio.

The sign of clockDiff in WebDirt is flipped as of dktr0/WebDirt@e166485. Flipping the sign back to the positive version produces sound when running a solo but leaving it negative results in silence. Essentially reverting

-      this.clockDiff = Date.now()/1000 - this.ac.currentTime;
+      this.clockDiff = this.ac.currentTime - (Date.now()/1000);

seemed to fix the problem without changing anything else but I don't know why.

Observation during rehearsal was shape parameters in miniTidal apparently not affecting playback via SuperDirt (superDirtSocket).

Punctual shaders disappear/stop working when leaving/re-entering an ensemble. They work with new ensembles only.

Sometimes seems to take anywhere from 1-6 load/reload attempts to get to the point where "click to start" works.

Hi, both TidalCycles and Punctual tutorials have the same problems. I tried on Firefox and on Chromium and the issue persisted.