Skip to content

Spectrogram Component #102

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kunitoki merged 5 commits into from
May 28, 2026
Merged

Spectrogram Component #102

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
1a65a54
Spectrogram Component
kunitoki May 22, 2026
94fe2ba
Merge branch 'main' into dev/spectrogram
kunitoki May 22, 2026
c895e4c
More tests
kunitoki May 25, 2026
09f8389
Merge branch 'main' into dev/spectrogram
kunitoki May 28, 2026
2aee874
More image tests
kunitoki May 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
233 changes: 73 additions & 160 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,42 @@ This document provides directive guidelines for AI assistants working on the YUP

**NEVER EVER run bash commands to configure, compile or test the implementation, acknowledge that we should test and we'll run and report any issue.**

## AI Decision Making Rules

### Always:
1. **Rely on the C++20 language and standard library** so use it (unless the feature is not supported in all YUP's platforms)
2. **Check existing patterns** in similar modules first
3. **Use YUP conventions** for similar functionality
4. **Use YUP infrastructure** instead of reinventing the wheel
5. **If the same functionality can be provided with less code and complexity** prefer less code
6. **Always prefer reusing code than creating duplicated code**
7. **Prefer composition over inheritance**
8. **Make classes small and focused** (single responsibility)
9. **Use const-correctness** throughout
10. **Do not leak internal details**
11. **Follow the open-closed principle**
12. **Never assume we use plain JUCE7 functionality, always check APIs** as they might have evolved

### When implementing new features:
1. **Always provide extensive and useful doxygen documentation** for public APIs
2. **Make sure new code is always tested**

### When writing tests:
1. **Test primarily public interfaces only**
2. **Cover normal, edge, and error cases**
3. **Use descriptive test names** (e.g., `ReturnsNullForInvalidInput`)
4. **Group related tests** in test fixtures
5. **Keep tests independent** and deterministic
6. **Never Use C or C++ macros (like M_PI)** use yup alternatives

### When suggesting refactoring:
1. **Maintain existing API contracts**
2. **Follow established module patterns**
3. **Preserve platform-specific code organization**
4. **Update tests accordingly**
5. **Consider performance implications**
6. **Keep API usage simple and effective**

### 1. File Headers
**ALWAYS** start new files with this exact header:

Expand Down Expand Up @@ -71,44 +107,6 @@ For main module headers (e.g., `yup_graphics.h`), include this declaration block
Refer to `./docs/YUP Module Format.md` for more info if needed.

### 3. Formatting Rules (Allman Style)
```cpp
// Classes
class MyClass
{
public:
MyClass();
~MyClass();

private:
int memberVariable;
};

// Functions
void functionName()
{
// implementation
}

// Control structures
if (condition)
{
// code
}
else
{
// code
}

for (int i = 0; i < count; ++i)
{
// code
}

while (condition)
{
// code
}
```

### 4. Naming Conventions
- **Classes:** `PascalCase` (e.g., `GraphicsContext`)
Expand All @@ -125,32 +123,30 @@ while (condition)
// 1. Own module header (if in .cpp file)
#include <yup_graphics/yup_graphics.h>

// 2. Standard library
#include <memory>
#include <vector>

// 3. External libraries (Rive, etc.)
#include <rive/rive.h>

// 4. Other project modules
// 2. Other project modules
#include "yup_core/yup_core.h"

// 5. Same module headers
// 3. Same module headers
#include "graphics/yup_Color.h"
#include "primitives/yup_Point.h"

// 5. External libraries (Rive, etc.)
#include <rive/rive.h>

// 4. Standard library
#include <memory>
#include <vector>
```

### 6. Namespace Usage
```cpp
// NEVER use "using namespace"
// In test files: OK for widely used namespaces
// NEVER use "using namespace" except in test files
using namespace yup;

// Prefer limited scope usage
TEST (MyClassTests, someFunction)
{
using namespace std::chrono;
// use chrono types without std::chrono:: prefix
}
```

Expand All @@ -166,8 +162,13 @@ modules/yup_module_name/
│ ├── yup_ClassName.h
│ └── yup_ClassName.cpp
└── native/ // Platform-specific code
├── yup_ClassName_win32.cpp
├── yup_ClassName_android.cpp
├── yup_ClassName_windows.cpp
├── yup_ClassName_linux.cpp
├── yup_ClassName_wasm.cpp
├── yup_ClassName_emscripten.cpp
├── yup_ClassName_mac.mm
├── yup_ClassName_ios.mm
└── yup_ClassName_apple.mm
```
Avoid going deeply nested into modules. Prefer a single subdirectory whenever possible for YUP modules (might be ok for thirdparties as we don't control the upstream structure).
Expand All @@ -183,33 +184,6 @@ tests/module_name/

## Class Design Templates

### Basic Class Template
```cpp
class ClassName
{
public:
ClassName();
~ClassName();

// Copy/move constructors if needed
ClassName (const ClassName& other) = delete;
ClassName& operator= (const ClassName& other) = delete;

// Public interface
void doSomething (int arg);
int getValue() const;
bool isValid() const;

private:
// Member variables
int value;
bool initialized;

// Helper methods
void initialize();
};
```

### YUP-Style Class (with leak detector)
```cpp
class YupStyleClass
Expand All @@ -221,6 +195,8 @@ public:
void publicMethod();

private:
void privateMethod();

int memberVar;

YUP_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (YupStyleClass)
Expand All @@ -239,15 +215,17 @@ using namespace yup;

namespace
{
// Test helpers and constants
constexpr int kTestValue = 42;

class TestHelper
{
public:
static void setupTestData() { /* ... */ }
};
}
// Test helpers and constants, prefer move them into fixtures so they don't clash in unity builds
constexpr int kTestValue = 42;

class TestHelper
{
public:
static void setupTestData() { /* ... */ }
};

} // namespace

class ClassNameTests : public ::testing::Test
{
Expand Down Expand Up @@ -279,54 +257,17 @@ TEST (ClassNameTests, StaticMethodBehavesCorrectly)
}
```

## AI Decision Making Rules

### Always:
1. **Rely on the C++20 language and standard library** so use it (unless the feature is not supported in all YUP's platforms)
2. **Check existing patterns** in similar modules first
3. **Use YUP conventions** for similar functionality
4. **Use YUP infrastructure** instead of reinventing the wheel
5. **Prefer composition over inheritance**
6. **Make classes small and focused** (single responsibility)
6. **Use const-correctness** throughout
7. **Do not leak internal details**
8. **Follow the open-closed principle**
9. **Never assume we use plain JUCE7 functionality, always check APIs** as they might have evolved

### When implementing new features:
1. **Always provide extensive and useful doxygen documentation** for public APIs
2. **Make sure new code is always tested**

### When writing tests:
1. **Test primarily public interfaces only**
2. **Cover normal, edge, and error cases**
3. **Use descriptive test names** (e.g., `ReturnsNullForInvalidInput`)
4. **Group related tests** in test fixtures
5. **Keep tests independent** and deterministic
6. **Never Use C or C++ macros (like M_PI)** use yup alternatives

### When suggesting refactoring:
1. **Maintain existing API contracts**
2. **Follow established module patterns**
3. **Preserve platform-specific code organization**
4. **Update tests accordingly**
5. **Consider performance implications**
6. **Keep API usage simple and effective**

### Platform-specific code:
```cpp
#if YUP_WINDOWS
// Windows implementation
#elif YUP_MAC
// macOS implementation
#elif YUP_IOS
// iOS implementation
#elif YUP_LINUX
// Linux implementation
#elif YUP_ANDROID
// Android implementation
#elif YUP_WASM
// WebAssembly implementation
#if YUP_WINDOWS // Windows
#elif YUP_MAC // macOS
#elif YUP_IOS // iOS
#elif YUP_LINUX // Linux
#elif YUP_ANDROID // Android
#elif YUP_WASM // WebAssembly (including emscripten)
#elif YUP_EMSCRIPTEN // WebAssembly (only emscripten)
#elif YUP_DESKTOP // Windows/macOS/Linux
#elif YUP_MOBILE // Android/iOS
#endif
```

Expand Down Expand Up @@ -375,34 +316,6 @@ Before suggesting code, verify:
- [ ] Thread safety considerations if applicable
- [ ] Documentation for public APIs

## Common Patterns to Follow

### Resource Management
```cpp
// Prefer RAII and smart pointers
class ResourceManager
{
private:
std::unique_ptr<Resource> resource;
std::vector<std::shared_ptr<Item>> items;
};
```

### Optional Values
```cpp
// Use yup::var for dynamic types
// Use std::optional for optional values
std::optional<int> findValue (const String& key);
```

### String Handling
```cpp
// Use yup::String for most string operations
void processText (const yup::String& text);

// Use std::string only when interfacing with non-YUP code
```

## Differences with JUCE

- We use American english in YUP, so it's `center` and not `centred`, or `Color` and not `Colour`
Expand Down
Loading
Loading