# \[New Module\] Melatonin Blur

**URL:** <https://forum.juce.com/t/new-module-melatonin-blur/58756>\
**Category:** General JUCE discussion\
**Created:** [November 10, 2023, 12:04pm UTC](https://forum.juce.com/t/new-module-melatonin-blur/58756 "2023-11-10T12:04:05Z")\
**Posts on this page:** 1\
**Showing post:** 42

<div class="post-metadata">

**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\
**Post date:** [December 25, 2023, 2:35pm UTC](https://forum.juce.com/t/new-module-melatonin-blur/58756/42 "2023-12-25T14:35:43Z")

</div>

> [@kunitoki](#):
>
> Seems rather an unnecessary dependency (maybe the juce team should consider moving the simd classes into a `juce_simd` module).

I strongly support this message (making `FloatVectorOperations` and related functions a separate module).

Would you mind suggesting that here (and voting, if you didn’t already)?

> [@FR: more compact JUCE module headers](https://forum.juce.com/t/fr-more-compact-juce-module-headers/50226):
>
> We have quite a lot (30+) custom JUCE modules used in multiple products, unit tests, etc, and I noticed that adding any JUCE module include to a module can really inflate compile times, compared to the same module without any JUCE includes. It would be great if some of these high level modules could be split into more compact modules. For example: I’m fine with juce\_gui\_basics bringing in a bunch of widgets, and no backwards compatibility should be broken for that module. But - in modules wit…

---

_[View the full topic](https://forum.juce.com/t/new-module-melatonin-blur/58756)._