Comments (4)
@chaosprint I'd love to take a shot at this, if you're not planning on doing it soon.
I also think this could be useful in implementing more robust docs, as all Node types could be in the same module and their doc comments could state how they should be used. (I also think it would be cool to make this documentation available in glicol-cli; not quite certain how that would work but I think it would be cool to have auto-generated information available inside glicol-cli about exactly what it supports)
from glicol.
Sure, feel free to take it on. For the cli, perhaps we can use https://github.com/mikaelmello/inquire in the future so that when users type glicol-cli
in the terminal, they will be asked to choose between:
- watch a *.glicol file and start the audio engine
- show help of a node usage (maybe fetch from github)
from glicol.
So I'm still working on this (I've got the ast parsing in glicol_parser
done, I'm trying to integrate it with the main crate now), and running into some issues with ergonomics. Specifically, I'm trying to make the parser zero-copy so that we can re-use the string allocations from the snippet of code we're parsing (and then just stick them together in a yoke::Yoke
or something), but that makes it hard for someone to construct an AST manually, if they want to use glicol
as a sound-creation library (instead of as a language-parsing library).
Do we want to make sure the AST can be easily programmatically created (i.e. make sure someone can create an AST without just parsing a snippet of code), or is that not a use-case we want this library to support? It wouldn't be too hard to support that (we could just make all the string borrows in the Ast enum be a Cow<'ast, str>
instead of &'ast str
so that someone could insert a Cow::Owned
when they want to programmatically make an Ast, or make the main Ast enum generic over T: AsRef<str>
, but both those add some complexity and unwanted side effects imo), but it seems to me that this library is mainly only intended to be used to process text, so I'm in favor of not really putting extra effort in to support other workflows.
What are your thoughts? (Also, did I explain this well? If you have questions, obviously feel free to ask)
from glicol.
So I'm still working on this (I've got the ast parsing in
glicol_parser
done, I'm trying to integrate it with the main crate now), and running into some issues with ergonomics. Specifically, I'm trying to make the parser zero-copy so that we can re-use the string allocations from the snippet of code we're parsing (and then just stick them together in ayoke::Yoke
or something), but that makes it hard for someone to construct an AST manually, if they want to useglicol
as a sound-creation library (instead of as a language-parsing library).Do we want to make sure the AST can be easily programmatically created (i.e. make sure someone can create an AST without just parsing a snippet of code), or is that not a use-case we want this library to support? It wouldn't be too hard to support that (we could just make all the string borrows in the Ast enum be a
Cow<'ast, str>
instead of&'ast str
so that someone could insert aCow::Owned
when they want to programmatically make an Ast, or make the main Ast enum generic overT: AsRef<str>
, but both those add some complexity and unwanted side effects imo), but it seems to me that this library is mainly only intended to be used to process text, so I'm in favor of not really putting extra effort in to support other workflows.What are your thoughts? (Also, did I explain this well? If you have questions, obviously feel free to ask)
Sorry for the late reply. I agree with you. There's no need to worry about making ASTs manually. If we're programming sounds instead of using Glicol syntax, we can just use what's in glicol_synth
.
Can't wait to see the zero-copy stuff!
from glicol.
Related Issues (20)
- Reverb got some noise...
- Support shared buffer to save memory space
- Help config Angular for Glicol HOT 1
- Add good real-time pitch shift and time stretch algorithm
- Use only one Rhai engine
- iOS or Android build? HOT 1
- Does glicol syntax resembles any other language? HOT 1
- tree-sitter parser HOT 2
- Feature idea HOT 4
- Panic when use specific code HOT 3
- Stop doesn't work in Glicol.js HOT 2
- API docs HOT 1
- Ideas List 2024
- Panic with this variation HOT 3
- Use `Result` in `process()` and other places
- Add `livecoding` toggle in glicol.js
- Trying to use glicol offline HOT 3
- audio distortion on studio display HOT 1
- consider making glicol-js independant
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from glicol.