Fork me on GitHub
#overtone
<
2023-11-06
>
plexus12:11:32

I wonder if @djuricsavo is still lurking here. Was just going over the blog posts they made for Clojurists Together. Would be good to add a "blogs" section to https://overtone.github.io/, and link them from there. I'd also love to see a "videos" page, with a curated set of youtube talks and performances.

diego.videco23:11:15

This may be an unpopular opinion/question, but is anyone bothered by the side-effectfulness of some of the overtone namespaces? Like loading overtone.core or overtone.live will trigger a bunch of things. I suppose that at the time they wanted to make things easier for new-comers; and from the live coding perspective it’s also nice to not have to type so much. But from a clojurian perspective it seems to me that it is not that nice to lack control of what gets executed when, and just to have effectful namespaces feels out of tune with the language. I feel similarly about bundling a version of scsynth. Seems to me like overtone tries to do too much for the user, and ends up being a very bloated package. It also makes it harder to maintain and to focus on the core functionality. By looking at the issues, it seems like it has problems in almost every platform. Even something like TidalCycles , which as user friendly as it is (language wise), doesn’t bundle supercollider. (To be fair, TidalCycles can be a pain to install, but it’s mostly the haskell side that gives trouble to people). Perhaps the question that needs to be defined now is what’s actually the scope of overtone? And what can overtone contribute in 2023? In my opinion (and my use case) it’s a great alternative to sclang and a contains a nice library for doing osc and midi. at-at is also great, but I feel the sequencing part built on top of it is the weakest. The use of freesound is a nice thing to have, but IMHO could be superseded by a very very thin wrapper for sending osc messages to SuperDirt (that is, if the focus of freesound is to make it accessible for users to prototype a piece of music). I think some nice features could be added on almost every one of the aforementioned aspects, but to me that’s the core of the value proposition. I feel trying to bundle scsynth is just too much and something that divests attention from the really important stuff. Additional libraries for music theory and for rhythm/sequencing could be added to the repo, as code, or dependencies or simply to the overtone organization, or to a curated and recommended list of extensions. I’d be glad to contribute my stuff over there. Perhaps a v2 that focuses solely on making the current overtone leaner would be a good thing to have, and a good platform to add new stuff and improve on what’s already there. If you all agree we can move this to an issue on the repo to continue discussing it.

soulflyer01:11:03

Yes, I'm bothered too. This looks like an epic though. I suspect breaking it into a number of issues would be a good thing. ie: • remove side effects on ns load • unbundle scsynth • spike to evaluate use of SuperDirt as an alternative to freesound • ?

👍 1
diego.videco02:11:05

Should be noted that the overtone.studio.scope ns relies on the internal server. But at this point I don’t know if really anyone that can use the internal server uses the scope. But I suppose that the SC scope would work pretty much the same.

plexus07:11:43

Thanks for starting this conversation! You make some good points. About the bundling of scsynth, I agree that this is one of the biggest obstacles to progress. The fact is that there is no one around who knows any more how to do a new build of that stuff, and it requires access to a linux, mac, and windows toolchain. You can't cross compile, you need xcode and visual studio. Currently we don't support mac m1/m2, on linux there are plugins missing, it seems we also don't support windows 64 bit(?). Good point about the scope, I've been wondering if there are really any benefits to running scsynth internally. I think a big reason they did it this way is to have something that's very accessible. I think Sam wanted Overtone to go mainstream, and because of that made certain choices to make it as plug-and-play as possible. What I have been thinking is maybe we should drop the internal scsynth, and instead download a supercollider release, unpack it (say in ~/.overtone/supercollider), and run that. So that overtone.live still "just works". In the end it's a small difference, wether we download libscsynth in a jar, or we download a sc-server release. About the namespaces, you're right that's not very idiomatic. Personally I find it less of a problem. Overtone is an atypical project, I think it's ok for it to bend the rules a bit. I rewatched Sam's conj talk about Overtone recently, and he mentions that "these are things you probably shouldn't do in your own project" (or something to that effect, I'm paraphrasing). It's not that they didn't know these were not best practices. It'd be good to have a critical look at what it's doing exactly, and to make sure it's factored well so it's possible to load it piece by piece and control the side effects yourself. But I tihnk it's ok to have a distinction between overtone.core and overtone.live, where one does side effects and the other doesn't. Let's maybe move these discussions to the mailing list? I prefer to keep repo issues for actual issues.

👍 2
diego.videco14:11:09

Yeah, let’s move this to the mailing list. Shall you do it or I?

plexus15:11:41

Go for it!

plexus14:11:56

@U7AMPCPU2 are you going to write that post or do you want me to do it?

diego.videco14:11:43

@U07FP7QJ0 yeah, will do asap (it’s just that past week was too busy for me)

👍 1