celealbe grazielle xaviera
Percival Blanco
It would be interesting if the creator, @qu1ck, was willing to post an estimate of the time and effort required to create this plugin (including, or not including, the prior years of experience writing software) .
About 3 days, leisurely 3-5 hours a day. That included fumbling about in inkscape to draw the icon as well as tracking down and fixing kicad buggy behavior regarding item selections and plugins. But I am pretty familiar with kicad codebase and API already and in general have >15years of writing software for a living.
So: what is the current advised way (for the latest 6.1.2 master release) to make it possible for a user to rescale the plugin editor window and its contents (including tooltips and combo/listboxes)?
When I did my experiments mentioned above, I saw some strange things with AAX plugins not resizing at all (unless you re-open the editor window) + also some strange tooltip placements. Does this method work for AAX plugins too (I actually ship VST2, AU and AAX)? And no tooltip placement strangeness?
When having multiple objects selected an applying a scale, currently the scale direction use the collective bounding box as the reference. This treats all selected objects as one entity and scales all aspects of it, including spacing. This is often not what I am looking for when using the scale tool.
This is also a behavior that I am looking for (coming from AI). I even found it in Inkscape but not here. This would allow to maintain the position of objects and rescale all of them to the same factor.
I think the easiest way, and prob the most quickest to implement from a developer perspective, is to allow users to add their own custom scales manually in its own little area/section and keep that section totally isolated from scaler2 existing scales. Kind of like this:
Then, after we lay down our melodies, and make progressions, we could drag those down into the pattern section, and start changing their voicing like any other normal chords. This should be pretty sufficient enough until you guys figure out a more clever way to integrate our custom user scales into the core of scaler2.
To expand the power & reach of Scaler, scales could be added that, when combined with tuning maps (e.g. scala) in aVI, would provide more culturally diverse options. So you load a scale into Scaler and you load a scala into some VI that accepts them and the combined scale & tuning system gives you authentic scales/chords/drones from many regions/cultures.
Hi @des1303 Yes indeed. Committed plan is a strong phrase but amongst other heavily requested user functions this is near top of the list. Has some limitations as to how it works in a live ecosystem but will happen at some stage.
I am eyeing Temporal for a decentralized FOSS application that will be part of the Fediverse. There will be many server instances that communicate with other instances and interop with other Fediverse applications using ActivityPub and ActivityStreams (actor-based protocol using JSON message exchange between inboxes and outboxes over HTTP).
A server typically hosts a small community of users (smaller is better) or is even self-hosted by a single person. Each server is a platform, where service modules (plugins) can be downloaded and dynamically added at runtime (was thinking of using Hashicorp go-plugin here). The core service would only provide basic features, with service modules providing (building blocks of) actual applications. Think similar to how Nextcloud platform works.
Prior to finding Temporal I was looking into a domain-driven design (DDD) with service modules corresponding to a Bounded Context or sub-domain and designed according to Ports & Adapters + CQRS/ES. Optional in this design was to have Proto.Actor actor model and have actors in the Application layer to load and cache domain aggregates.
Default install would be for small-scale use, and having a SQLite database. The service modules would run on the same server, so not a true microservices design (though communication uses gRPC). Scaling up and out would be needed in rare cases, and then Postgres is available as db (a large-scale service instance would have 50-100k users).
The above may make no sense, not work. Shows my noobness on the paradigm shift that Temporal seems to offer. A safe architecture design would be to have the ports & adapters, DDD, CQRS/ES as I intended, but having Temporal only provide Saga capability and handle some clearly long-running tasks.
Yes, but the read-site of CQRS would offer denormalized views on the data. But I think you mean to say this is the way to get at workflow state for implementing the read-side, which then has its own way of dealing with persistence.
Is Temporalite with Litestream suitable for small-scale production use cases now? In December, it was one of the ambitious goals of Temporalite to integrate with Litestream to run on standalone servers. Just checking if this was currently advised against, or just experimental and not fully tested. Thanks!
Litestream aims to provide a balance between durability and operational complexity by batching changes into one-second windows and asynchronously backing those changes up to external storage. This improves write performance at the expense of having a small window of data loss in the event of a catastrophic failure.
Okay, so I recently updated to the latest version of the PulseAudio plugin for Xfce4 that was pushed to Arch's stable repos, and this is now how the icon appears on my panel. Current panel size is 32; the icon seems to go back to its size that was present in the previous version when I drop the panel's length to 26, but this is far too small for me.
I've the same problem since update xfce4-pulseaudio-plugin in 2.5.1 on Arch Linux stable. CSS doesn't change anything because it's the button size who is not correct and we can't change that by css but only in library code.
I also use Adapta and Paper.
My panel size is to 30. And before the update (2.4.1), icon was in good size.
If i reduce panel size to 24, it's okay. CSS doesn't change anything for me. I've purposed a patch for that.
ToZ, I appreciate you telling us a way to change the size of the symbolic icons. Fixed my issue with the Clipman plugin, too! The issue with the PA plugin still stands, sadly, but I can live with it until a bugfix release gets pushed out. If not, I'll submit a bug report to find out if the package maintainer can implement the upstream patch.
Hey guys, sorry to necro an old post, but I'm having the same issue. If preferable I can start a new thread.
The icon seems to stay the 'correct' size as long as the panel is 35 or smaller, but anything over 35 and it becomes the giant icon.
Here is how it looks, a bit out of touch with the rest:
Works perfectly! Thanks a bunch ToZ!
Edit: Also resized the whiskermenu-button with that, since it also looked a bit too big. If you don't mind me asking, is there any place to see the names/attributes from each icon if I wanted to change them?
Remember to edit the subject of your topic to include the [SOLVED] tag once you're satisfied with the answers or have found a solution (in which case, don't forget to share it as well), so that other members of the community can quickly refer to it and save their time. Pretty please!
I have my display scaled for ease of reading, but this makes Plugin windows appear enormous when using Logic Pro X. Is there a way to make them appear about 50% of the size? I seem to remember this being an option a few versions of Logic ago, from the "View" menu at the top of the plugin, but a) I often can't get to the "View" menu because the Plugin is so big, and b) the scaling options don't seem to be there anymore.
The View menu still exists in the plug-in header.
You can also drag the lower left/right corners to resize plug-in windows.
Rather than scaling the entire display, have you experimented with the various accessibility features and used default functions such as zoom: Option Cmd - and Option Cmd =
You can also adjust text size here.
Logic also provides several display options in Settings>View>General.
Large Local Menus
Wide Playhead
a.s.o.
Thanks for your reply. I've tried a few different screen resolutions and I'm happy with the one I've chosen, it's the best for overall accessibility without sacrificing too much screen real estate. The Plugin windows are really the only time it's a problem.
Some Plugins don't give the option to resize in the "View" menu unfortunately. Also, in these cases, dragging the lower corners simply moves the window, rather than resizing it (I have placed the cursor at the very edge of the window, makes no difference).
Third-party plugs?
If so, many (such as the Arturia plugs) have a settings menu or icons where this can be done.....or the resize by dragging a corner feature (the pointer shows a two-headed diagonal arrow if the cursor is in the correct "click/mouseover zone").
Catch-22 is that a number of third-party plugs simply can't be resized....and this limitation can only be resolved by the plug-in developer - it's not something that Apple can address in Logic. i.e. the resizeability is a function of the plug-in itself as it contains the larger/smaller graphics/vector art, fonts, etc. - depending on the approach taken by the developer and requirements of the plug-in.
Have you considered/is it practical in your Logic working situation to use an additional monitor?
If so, Logic can work across multiple screens (of the same or different resolutions) and you can freely reposition plug-in windows as/where you wish.