HN user

graphitout

40 karma

Working on representing scientific knowledge using dependency graphs.

Posts5
Comments28
View on HN

For a chatbot like claude code, since the instruction prompt part (including descriptions of tools) is relatively constant for multiple users and over a long time, a lot of optimizations can be made. Even basic prompt caching gives a lot of speed and cost reduction.

Claude gave me $50 yesterday with the release of opus4.6 and I burned my session quota + $30 yesterday itself. The code changes were very reasonable.

It is good for handling all code changes where there are no security aspects involved.

The RAG was setup on a bunch of documents, most of them were manuals containing steps about measurements, troubleshooting, and replacing components of industrial machines.

The issue was that most of these steps were long (above 512 tokens). So the typical chunk window wouldn't capture the full steps. We added a tool calling capability by which LLM can request nearby chunks of a given chunk. This worked well in practice, but burned more $$.

optimal chunk size is strongly query-dependent - very true.

Faced similar issues. Ended up adding a agentic tool call layer on the top to retrieve the nearby chunks to handle a case where a relevant answer was only partially available in a chunk (like a 7 step instruction in which only 4 were available in a chunk). It worked ok.

You are right.

- llm_generate() - this is the core function which calls ollama API

- get_related() - this will give a sequence of related topics for a given topic and description

- llm_get_aspect_query() - this is tricky. The interface has a fixed set of aspects for every response. Like history, related ideas, people etc. I wanted a way to create new query based on an existing query and a given aspect. This func does the rephrasing of the query.

- App.vue: handle_related() - there is a tiny bit here. When going to another "suggested" topic, it seems we have to give it some context.

Additive synthesis was a pain to configure. I had to model and estimate the behavior of each harmonic. It was too much effort.

Subtractive synthesis didn't work that well for me either. I believe my implementation of the variable cut off lowpass filter had something to do with it.

FM Synthesis worked reasonably well without much effort. Implementation was rather straightforward.

You are right.

I needed that image to explain the parameters in the ADSR configuration I used in the project. Mainly the slevel1 and slevel2 which captures the slow decay during sustain. Most ADSR diagrams show sustain as a constant which didn't really sound that natural when I tested for my projects.

I had some fun with the strings in the karplus-stress-tester. Thank you for that link.

I am thinking of moving the core to WASM. But I may have to drop the python part and make the calls directly from javascript.

Glicol looks impressive. I will try it out.

[dead] 3 years ago

Is there a way to test it out without login?

I can understand your frustration. I was banned from Google ads and to this day I have no clue why. I was selling a speech recognition product. I appealed once, but it didn't get anywhere.

These big companies don't care much about small users and can be quite nasty in their language. They have no interest to make the process fair because they have all the power.