Skip to content

Commit

Permalink
more todo
Browse files Browse the repository at this point in the history
  • Loading branch information
magnetophon committed Jan 5, 2025
1 parent 454c856 commit 5530f40
Showing 1 changed file with 35 additions and 14 deletions.
49 changes: 35 additions & 14 deletions todo.org
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,27 @@ trials
marketing
*** alternatives:
https://www.kvraudio.com/forum/viewtopic.php?t=612462&start=15
*** Marius from CrispyTuner
https://discord.com/channels/590254806208217089/780426792984772608/1325418934869950517
@magnetophon answering here to have it in a more fitting channel:

I am using Moonbase for licensing, because it solves 2 problems at once:

First of all, it acts as a Merchant of Record, meaning customers buy the license from Moonbase instead of your company. If they were to buy from you directly, you'd have to declare taxes in every country any of your customers sit in. And that gets really complicated really fast when you sell internationally.

A more well-known Merchant of Record would be Fastspring or Paddle - I myself used Fastspring when selling the CrispyTuner. But basically, you definitely need one. The big advantage of Moonbase over Fastspring is that Moonbase offers an integrated Licensing solution. When using Fastspring for the CrispyTuner, I had to implement my own license system and host my own license servers, which is not required here!

The way licensing with Moonbase works is fairly simple, and basically identical to the system I implemented myself back in the day - after entering a license key, the license server sends a JSON payload that is signed with the license server's private key. The plugin then validates the payload's signature with the license server's public key to check whether the payload is authentic, and then checks the contents to see whether it's a valid license for this product.
I then store this payload on the user's computer so that for future activations, the user doesn't always have to be online to get the payload. Since Moonbase supports revoking and transferring licenses to a different machine, I will still require them to be online at least once a month to refresh the token. However, Offline activation is also an option, in which case the payload never expires but also can't be revoked by the user (only by the merchant, aka myself).
Moonbase
Delivery platform for great software
[12:03 PM]
The payload sent by Moonbase is standardized in JWT format, so I can just use one of Rust's JWT parsing crates jsonwebtoken to do all of the validation for me. Therefore, implementation is rather simple, I think I'll get it all done in less than 200 loc
[12:05 PM]
The only "downside" of Moonbase rn is that it's somewhat new, but I know of 2 people who are using it in production without any issues. To get access to their platform, you need to have an onboarding call with them, cause they don't want people to sell illegal stuff on their platform. If you end up checking it out, tell Tobias that Marius sent you, he's gonna love me for it 
Marius — Today at 12:08 PM
to the user, the flow is as follows: buy plugin, with or without creating an account, and then when first starting the plugin, there's an "Activate" button that opens their browser where they are likely already logged in to their account. Then, they can immediately return to their DAW and use the plugin!

** tap/meter life cycle
*** create tap 0,1,2
Expand All @@ -34,6 +55,7 @@ always lowest N
N = tap_counter, is not the same as nr of active taps, cause taps can be releasing
match tap_index with run_index

*** life-cycle summary
| event | tap_index | run_index | nr taps | simd_width | run_at_simd | display_at_meter | action |
|-----------------------+-----------+-----------+---------+------------+-------------+--------------+----------------------------------|
| 1 new | 0 | 0 | 1 | 2 | 0 | 0 | |
Expand All @@ -49,29 +71,28 @@ match tap_index with run_index
| 11 new | 4 | 2 | 5 | 16 | 3,4,0,1,2 | 3,4,0,1,2 | 3,4,0,1 from sim8 -> sim16 |
| 12 new | 5 | 5 | 6 | 16 | 3,4,0,1,2,5 | 3,4,0,1,2,5 | |

*** lookup table
**** example tables
***** simd_nr
this is the key to the table
range: 0..nr_taps_alive
***** run_at_simd
*** example tables
**** simd_nr
his is the key to the table
ange: 0..nr_taps_alive
**** run_at_simd
which run_index are we processing at this simd_nr
***** display_at_meter
**** display_at_meter
which meter should we write this simd_nr to?


**** spelled out tables:
1) new
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 0 | 0 |

2) new
2) new, simd 2 -> 4
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 0 | 0 |
| 1 | 1 | 1 |

3) new
3) new, simd 4 -> 8
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 0 | 0 |
Expand All @@ -90,7 +111,7 @@ which meter should we write this simd_nr to?
| 2 | 2 | - |
| 3 | 3 | 0 |

7) new
7) new, simd 8 -> 16
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 0 | - |
Expand All @@ -99,13 +120,13 @@ which meter should we write this simd_nr to?
| 3 | 3 | 0 |
| 4 | 4 | 1 |

8) run 0,1,2 released
8) run 0,1,2 released, simd 16 -> 4
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 3 | 0 |
| 1 | 4 | 1 |

9) new
9) new, simd 4 -> 8
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 3 | 0 |
Expand All @@ -120,7 +141,7 @@ which meter should we write this simd_nr to?
| 2 | 0 | 2 |
| 3 | 1 | 3 |

11) new
11) new, simd 8 -> 16
| simd_nr | run_at_simd | display_at_meter |
|---------+-------------+------------------|
| 0 | 3 | 0 |
Expand Down

0 comments on commit 5530f40

Please sign in to comment.