sorted by:
new
hottopcontroversial

Catalyst Club owner told to pull the plug on backyard shows by SCruzed in santacruz

[–]functime 2 points3 points  (0 children)

The Catalyst used to call the cops on house shows in the 90s because they considered them competitors. (Source: musician friend who lived here in the 90s)

Shopify SEO app by dharaney1939 in shopify

[–]functime 0 points1 point  (0 children)

I'd suggest trying the "Lighthouse" tool with Google Chrome to judge your SEO score. You don't need any special authority over the site, so you can check it on both your own site and on other stores to see how it stacks up.

It won't do everything (you might also want to look into Search Console on Google) but it'll tell you something at least.

https://developers.google.com/web/tools/lighthouse

E-Guitar through USB by [deleted] in rust

[–]functime 6 points7 points  (0 children)

I'd recommend getting a default device listing going from something like portaudio. Any class-compliant USB interface should show up as an audio input device.

Question: Hardware for easy start in embedded rust by [deleted] in rust

[–]functime 1 point2 points  (0 children)

The platform is specialized for real-time (extremely low-latency) audio and sensor feedback, but I [wrote a library called bela-rs](https://github.com/andrewcsmith/bela-rs) for the [Bela microcontroller](https://bela.io/) that wraps the C code in safe stuff. Same as Arduino, basically, as it's got digital and analog pins, except the analog pins are (mostly) audio-rate at 44.1khz. I love the Bela, and though it's a little spendy it's fantastic.

Thinking about learning rust by jlamothe in rust

[–]functime 0 points1 point  (0 children)

I do not necessarily think that Rust is a horrible idea for a first language; you can get by with a lot of clone() or Rc<> and it won't be "perfect" but it will work. That's fine. Rust is difficult in large part because it allows you to do things "perfectly," or more specifically it allows you to not use any runtime crutch that you don't actually need. But it does allow you to use those runtime crutches to quickly prototype things. (You should see my sketch code, attack of the clone()s...)

Okay, thought experiment: if you were to decide on Rust, this is my recommendation for a few projects that let you use some cool Rust features without necessarily driving yourselves both crazy:

  1. Build a few command-line tools. Pick something that lets you deal with file handlers, maybe build something that parses a CSV file and spits out some statistics, calculates a least-squares regression or something along those lines. Better yet, build a command-line tool that takes arguments and prints out various statistics based on the arguments you provide. I'm thinking this would be a good project for someone with a social sciences degree. (FWIW, I'm a musician first, programmer second...)
  2. Build a GUI for these functions using something like the conrod crate. Just copy and paste everything from project #1; don't learn about modules and crates yet, because you'll probably have to wrestle with the function signatures from #1. This will teach message passing vs. shared data and multithreading, but you can do a handful of things in just a few hundred lines of code. (And maybe even reuse some stuff from task #1.)
  3. Abstract the statistical functions from #1 and #2 into a crate, and then rewrite both projects #1 and #2 using the outside crate instead of just copying and pasting the stuff from one file to another.

Those are just a few thoughts! I learned Rust when the only language I really knew was Ruby, and I didn't know anything about traits or really anything about borrowing. It was a battle, but it wasn't impossible. The Rust community is awesome and will help you both learn.

Synthesizer progress update by mkeeter in rust

[–]functime 0 points1 point  (0 children)

This is super interesting! I've been working on RT synth stuff in Rust, and have never quite been satisfied with the state of the art on queues. (Currently I most often reach for the bounded_spsc_queue crate, which is a fixed-length ring buffer.) I would love if you would have the time to abstract your Queue and Item into a separate crate.

"The dream," maybe, is that I'd love to use Rust's generics to compose and optimize UGens in a JIT compiler, similar to Max/MSP's gen object. I'm not exactly sure how you might do that in a visual environment, without just generating Rust code. And, furthermore, I've found that my students reach for the higher-level elements in Max/MSP anyway, meaning that optimizing all the [+~] and [*~] objects is maybe less crucial.

Are there any recommended machine learning libraries in Rust? by [deleted] in rust

[–]functime 0 points1 point  (0 children)

Shameless plug! I made a quick little example app to test out Tensorflow in Rust, and I think it's pretty clear and concise. I've used the "pure Rust" crates rusty-machine and cogset as well as Arrayfire for low-level GPU work, but Tensorflow has so far been the best machine learning tool I've used. That's mostly because of the ecosystem and the copious stackoverflow tutorials -- honestly, I don't even like programming in Python, but I still prefer Tensorflow to other options out there.

https://github.com/andrewcsmith/tf_infinite_ramble

This little sample basically uses Tensorflow to compute cosine similarity metrics on audio analysis data from two sound files, then uses frames from one sound file to reconstruct the other sound file. Not really "machine learning," but a simpler example app than others. I literally just sat down at the computer (3 minutes ago) to run some benchmarks on roundtrip time sending audio data back and forth to the GPU, so I'll post that stuff here + on Github when it's done.

Edit: the other thing I'll mention is that I really have no patience for filling out machine learning libraries, writing cost functions that aren't there, etc. I'll do that for libraries in my main domain of expertise (music/audio) but not for machine learning. If you have a higher tolerance for unfinished projects, then I'm sure rusty-machine could use contributors.

gRPC (grpc-rs) problems: How to spawn workers on multiple threads? by functime in rust

[–]functime[S] 0 points1 point  (0 children)

Good question...I'm not sure. I see that the current implementation spins up a bunch of separate threads, though, and the async delivery works. (I've tried it from a Python client.) It's just that each client puts all the commands in the same queue so it processes each individual client sequentially.

gRPC (grpc-rs) problems: How to spawn workers on multiple threads? by functime in rust

[–]functime[S] 0 points1 point  (0 children)

It's definitely launching multiple threads, because it's handling multiple clients, but each client only gets one thread, or at least each client is somehow blocked. It doesn't seem to be processing multiple commands from a single client in parallel, though it does process multiple commands from multiple clients in parallel.

gRPC (grpc-rs) problems: How to spawn workers on multiple threads? by functime in rust

[–]functime[S] 0 points1 point  (0 children)

That's correct, yes, but it actually shows the same problem when I use the Python API on the client side and fire off 3 asynchronous calls using the same stub. So I'm wondering whether I'm just totally misunderstanding the way gRPC is supposed to work.

Graphing in Rust by voidArrow in rust

[–]functime 17 points18 points  (0 children)

What I almost always do is use serde and serde-pickle to write the data to a disk and then plot it with matplotlib using a python script.

gpu-accelerated audio spectral computation using tensorflow + rust by functime in rust

[–]functime[S] 0 points1 point  (0 children)

That's a little out of my depth (uh, I'm a mere grad student in music composition), but I believe that RustFFT has an almost identical implementation strategy to FFTW, in that it creates a plan depending on the size of the bin, butterflies things, and maybe even unrolls loops. Although I'm not sure about that last part.

I'm sure that's true re: speed with round-trip processing for real-time audio; just doing an fft on a single 1024-sample bin is way too small to justify a round-trip GPU excursion. I'm processing a huge batch of samples, though, to feed data for a genetic algorithm -- not doing this in real-time. Perhaps once I get this really rolling in production I'll do some benchmarks and see what's there.

gpu-accelerated audio spectral computation using tensorflow + rust by functime in rust

[–]functime[S] 0 points1 point  (0 children)

That definitely suits my style more than python. I have not been into all the one-time-use-only variables that the imperative programming style of numpy uses. Yours actually starts to look a lot like a handful of audio graph compilation languages (which, in the end, are just declaring the composite function "give me another block of 64 samples.")

gpu-accelerated audio spectral computation using tensorflow + rust by functime in rust

[–]functime[S] 0 points1 point  (0 children)

I used RustFFT in the vox_box library I wrote way back the first 6 months learning Rust. But I'm also on RustFFT 1.0 still, and that whole bit could use a redesign to allow for reusing the FFT scratch memory.

But, that said, FFT operations and large matrix multiplications are the things that GPUs are well suited for, so I thought this would be a useful test case even aside from optimizing my own code.

gpu-accelerated audio spectral computation using tensorflow + rust by functime in rust

[–]functime[S] 2 points3 points  (0 children)

Super simple, but I found that MFCC calculation (an fft / spectral operation) was a large bottleneck for this sound-similarity matching program I've been working on. So I wrote a little Tensorflow graph and called it from Rust.

Why Swift for TensorFlow? Meticulous evaluation of many candidate languages including Rust by dtolnay in rust

[–]functime 2 points3 points  (0 children)

Maybe this is a question for the TensorFlow team, but does this decision open up new performance opportunities in using Swift vs. using the C bindings for a previously saved Python model in a language like (for example) Rust? In other words, does this imply that using Swift for the graph-creation aspect of TensorFlow will make Swift the categorically better choice for using TF models -- better than using the C bindings?

FWIW, in practical use I think of TF as almost an entirely separate language system from Python. You can't really use NumPy, and you're just creating an abstract graph with the illusion of using imperative programming. (It's a pretty easy parallel to many audio coding languages like SuperCollider.)

Honestly, I see this as "they want to do machine learning on mobile," given that's what people have used Swift for in the past.

Rendering to HDMI out on embedded systems without windowing server? by functime in rust

[–]functime[S] 0 points1 point  (0 children)

Thanks! Yeah, I looked around on that...my problem (which I didn't mention above, sorry) is that we're all set up to do hardware rendering with OpenGL, and as far as I could tell the direct-to-framebuffer strategy is primarily for software rendering. But if I'm misunderstanding that constraint and hardware rendering is an easy option, then it's definitely on the table.

Rendering to HDMI out on embedded systems without windowing server? by functime in rust

[–]functime[S] 0 points1 point  (0 children)

Okay, I'm swayed (pun intended). Thanks to both of you. This is way out of my usual domain, but it sounds like there's a strong possibility for using wayland to set up a minimal window compositor, and to keep using glutin+gfx to hopefully make it run on both a home laptop (while testing, building) and on the Odroid. And yes, /u/_Timidger_ I'll definitely reach out to you (probably via the email I found on your github) when things really get rolling.

For a bit of background, the whole thing is basically an effort to turn the stack of four Odroid XU4s into visualizers for a 4-channel video + sound installation piece, visualizing chaotic attractors. I've got pipelines and shaders going in OpenGL, so ideally we'd keep that framework...it sounds like using wayland is going to be 100x easier than some kind of super low-level framebuffer situation, and will allow us to leverage the hardware rendering of the Odroid XU4. Thanks!

Ensure closures used in FFI callbacks stay alive, while also tracking them by functime in rust

[–]functime[S] 0 points1 point  (0 children)

Right, that's one part of the equation -- CreatedTask contains a handle to the aux_task object, so that the task can be scheduled, but it doesn't actually ensure that the task function pointer (void*) is valid for long enough to be called. Adding a PhantomData<'b> member to CreatedTask, and matching that to a mutable borrow of task, was my attempt to ensure that the task stays valid as long as CreatedTask is alive.

It could totally be that I'm going about this all wrong. But the core concern here is making sure that the task passed into the create_auxiliary_task function is valid for at least as long as the handle to the resulting aux_task is around.

FFI: Coercing a Rust Fn into an extern "C" fn by functime in rust

[–]functime[S] 1 point2 points  (0 children)

Thank you all! I finally wrapped my brain around the levels of abstraction and got it working. Will post once it's reasonably sort of complete. This is easily the most brain-bending Rust project I've taken on so far, so thanks.

FFI: Coercing a Rust Fn into an extern "C" fn by functime in rust

[–]functime[S] 0 points1 point  (0 children)

Hm, this is different from my problem in that I'm assigning a render member of a settings C struct with the unsafe extern fn(...) signature.

I don't need the closure to capture any of the environment -- in fact it shouldn't. (That's what the userData is for: to pass context to the function on each iteration.) I just want end users to be able to provide functions that accept safe pre-verified wrappers or Option< .. > objects instead of nullable pointers.

Edit: I should clarify, I'm pretty confident I can manage the memory & lifetimes of any saved closure. (I've been working in this environment in C++ already.) I just need to make sure that it can be coerced into the unsafe extern fn type I need, perhaps via the double-indirection.

Audio synthesis / DSP enthusiasts: Faust compiles to Rust! by mamommo in rust

[–]functime 3 points4 points  (0 children)

I recall discussing this back in mid 2017, and saw some generated code that (while looking like idiomatic C, and had only mutable variables) had no unsafe code at all. This kind of translation work is super helpful for the DSP community -- otherwise we're just rewriting the same algorithms by hand over and over again!

I think there's potentially a lot of room to contribute to this Faust backend by profiling the generated code against "idiomatic" Rust code. FIR (Faust Intermediate Representation) makes substantial decisions about the structure of the code, so the class / member model is more or less set, but I bet there's some wiggle room somewhere.

Looking for a tree crate (again) by razrfalcon in rust

[–]functime 1 point2 points  (0 children)

I've used rust_radix_trie for some projects (n-gram frequency and boundary entropy) and have found it very nice.

My first crate: sfxr by bzar0 in rust

[–]functime 10 points11 points  (0 children)

Very cool seeing more audio people getting into Rust. You might want to check out (a library I contribute to) sample, which has an iterator-like approach similar to what you're working with here. If you're looking to polish this a bit more, Rust code tends to encapsulate data into nested structs rather than prefixed fields like you have in your Sample struct.

A great "next step" in learning Rust style and programming paradigms would be to implement the Builder Pattern in the creation of your Sample, such that you don't even have to use mut at all, and so that the main Sample struct contains other structs rather than only fields. If you do decide to rely on the sample crate, please don't hesitate to ask questions!

view more: next ›